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ABSTRACT 


After the attacks of 9/11, increased security became a national priority that 
resulted in a focus on National Maritime Security. Maritime Domain Awareness (MDA) 
is an initiative developed by the Coast Guard, in partnership with the U.S. Navy and other 
agencies to increase awareness in the maritime domain in support of maritime security 
[Morgan and Wimmer, 2005]. 

The purpose of MDA is to generate actionable intelligence obtained via the 
collection, fusion and dissemination of information from U.S. joint forces, U.S. 
government agencies, international coalition partners and commercial entities. This 
actionable intelligence is the cornerstone of successful counterterrorist and maritime law 
enforcement operations and is critical to Maritime Security [Morgan and Wimmer, 2005]. 

The U.S. Navy, as a partner in the development and creation of MDA, has tasked 
its subordinate commands to identify and define capabilities to support this program. One 
effort sponsored is the Comprehensive Maritime Awareness (CMA) Joint Capabilities 
Technology Demonstration (JCTD) [CMA Architecture Team, 2007]. This project 
supports the CMA JCTD efforts by proposing a deployable system to enable a 
disconnected vessel to connect to the CMA network. A disconnected user can be seen as 
a merchant ship, hospital ship or any vessel that is not currently connected to the CMA 
network. This project’s proposed deployable system, as a subset to the CMA network, 


facilitates information sharing in support of humanitarian efforts worldwide. 
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EXECUTIVE SUMMARY 


After the attacks of 9/11, increased security became a national priority that 
resulted in a focus on National Maritime Security. Maritime Domain Awareness is an 
initiative developed by the Coast Guard, to increase awareness of activities in the 
maritime domain in support of maritime security [Morgan and Wimmer, 2005]. The 
purpose of MDA is to generate actionable intelligence obtained via the collection, fusion 
and dissemination of information from United States (U.S.) joint forces, U.S. government 
agencies, international coalition partners and commercial entities. This actionable 
intelligence is viewed as the cornerstone of successful counterterrorist and maritime law 
enforcement operations and is critical to Maritime Security [Morgan and Wimmer, 2005]. 

The U.S. Navy has tasked its subordinate commands to identify and define 
capabilities to support this program. One such effort is the Comprehensive Maritime 
Awareness (CMA) Joint Capabilities Technology Demonstration (JCTD) [CMA 
Architecture Team, 2007]. 

This extending Comprehensive Maritime Awareness (xKCMA) project augments 
the CMA JCTD by addressing the requirements and functions required to connect the 
user vessel into the CMA network. These vessels will hereafter be referred to as 
disconnected vessels, or Node 5’s, where detailed definitions of Node 5’s will follow in 
this report. 

Using a tailored system engineering process, identified in detail in the following 
report, system alternatives were developed and evaluated based on stakeholder defined 
key system parameters. Four primary alternatives were recommended and evaluated 
based on reliability and throughput simulations resulting in a recommendation. 

The resulting recommendation indicates all four options are viable systems and 
are capable of providing a solution to the problem; however, as this report shows, the 
Satellite Communication (SATCOM) with a Single Board Computer (SBC) alternative, is 
the higher ranked configuration for extending CMA to a disconnected node in support of 
humanitarian efforts. In this approach, a SATCOM capability is used as the 


communications means for connecting to the CMA network. The information from the 


Xlil 


host system consisting of an SBC, modem/router, power supply, display, and input 
devices packaged in a ruggedized, transportable container is routed through the 
modulator demodulator (modem) and then transmitted by the satellite transmitter to the 
Node 4 satellite receiver (Node 4 details are to follow). The information from Node 4 is 
transmitted by a satellite transmitter and received by the system satellite receiver and 
demodulated for processing by the host system. The Network Interface Card (NIC) 
provides the system with a unique hardware Media Access Control (MAC) address for 
system identification. A Commercial-Off-The-Shelf (COTS) Global Positioning System 
(GPS) receiver is used to provide system Position Location Information (PLI). This 
recommendation provides a solution to enable the connection of a disconnected vessel to 


the CMA network. 
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I. INTRODUCTION 


The evolving need for distributed information in support of national maritime 
security policies has given rise to the concept of Maritime Domain Awareness (MDA). 
The need for distributed information has been addressed at the National, Department of 
Defense and U.S. Navy levels. A Joint Capabilities Technology Demonstration (JCTD) 
effort titled Comprehensive Maritime Awareness (CMA) began in 2006 and intends to 
improve MDA through the demonstration of interagency and international information 
exchange. The focus of this engineering study is to augment the CMA JCTD efforts by 
defining the functional requirements, architecture, and systems required to extend CMA 
to disconnected users and vessels. The results include a recommendation based on the 


evaluation performed using a tailored systems engineering development processes. 


A. BACKGROUND 


MDA is an initiative developed by the Coast Guard, in partnership with the U.S. 
Navy and other agencies to increase awareness of activities in the maritime domain in 
support of maritime security [Morgan and Wimmer, 2005]. It evolved as a result of the 
threat and security challenges incurred in the Post 9/11 Era and was mandated by 
President George W. Bush in 2004 [White House, 2004]. 

The purpose of MDA is to generate actionable intelligence obtained via the 
collection, fusion, and dissemination of information from U.S. joint forces, U.S. 
government agencies, international coalition partners and commercial entities. This 
actionable intelligence is viewed as the cornerstone of successful counterterrorist and 
maritime law enforcement operations and is critical to Maritime Security [Morgan and 
Wimmer, 2005]. 

MDA is the result of the proper integration of a diverse set of capabilities, which 
provide decision makers with an effective understanding of the maritime domain. This 
effective understanding supports the decision making process and facilitates operational 


response. Achieving MDA depends on the ability to persistently monitor the four MDA 


pillars (vessels, cargo, personnel and infrastructure), and scrutinize activities in day-to- 
day operations in such a way that trends and anomalies can be identified. 

The CMA JCTD intends to demonstrate the effective and efficient use of data 
management strategies and automated tools. The goals of the CMA JCTD are to address 
the identified gaps with effective and efficient prioritization of maritime threats and to 
enable proper allocation of security resources in the maritime environment. Residuals of 
the CMA JCTD include, but are not limited to, an architectural structure, concept of 
operations, core collaborative toolsets and technology evaluation. 

A gap in this implementation is the capability to connect a non-CMA vessel or 
entity to the CMA environment. This capability gap is the focus of this project effort, 
which defines the architecture, system requirements, and effort needed to facilitate the 
extension of CMA (xCMA) to disconnected vessels and users. The effort addresses the 
capabilities and capacities required to provide timely and accurate maritime situational 
awareness, in the form of their User Defined Awareness Picture (UDAP), to the 


disconnected nodes. 


B. PROBLEM STATEMENT 


The Chief of Naval Operations (CNO) noted that the navies are not only 
important in the execution of operations in support of wartime efforts, but are also 
“instruments of peace” and stressed the need for a global network of maritime nations. 
This network provides a collective response to all participants enabling a global 
perspective of the maritime domain that is essential for national security, global stability, 


and economic prosperity [Green, 2007]. 


This global network does not currently exist and addressing a suitable network is 
the primary goal of the CMA JCTD currently ongoing under the direction of Program 
Executive Officer, Command, Control, Communications, Computers, Intelligence (PEO- 
C4I). This thesis augments the work being completed by the CMA activities to facilitate 
continued information sharing. The specific focus is on the evaluation of the CMA 
architecture and the identification of modifications and systems required to ensure that 


disconnected vessels are active participants in CMA. 


Cc. KEY TERMS AND DEFINITIONS 


The definition of key terms is essential to understanding the scope of this effort. 
The intent of the following paragraphs is to identify these definitions as they pertain to 
this effort. 


1. Comprehensive Maritime Awareness 


CMA is an MDA implementation with a goal of addressing serious gaps in the 
ability to identify and prioritize maritime threats. The CMA architecture consists of three 
categories of nodes: user, operational, and enterprise. The CMA efforts have been 
focused on the requirements and implementation of the operational and enterprise nodes, 
depicted in the Operational View (OV-1) as Nodes 1-4, as shown in Figure 1. The user 
node, Node 5, has had limited evaluation to date and is being addressed by this thesis to 
augment the parallel efforts of the CMA JCTD. 


Maritime Domain Awareness 
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Figure 1. Comprehensive Maritime Awareness Operational View (OV-1). 

Source: CMA JCTD Interim Report on Architecture draft version 0.2 (2007) by David R. 
Reading [Reading, 2007]. This OV-1 provides a pictorial representation of the 
connections and node interactions as referenced in the CMA Architecture. 


Nodes | and 2 are the primary and secondary nodes, with Node 1 functioning as 


the central repository, and Node 2 as the replication backup. Nodes 3 and 4 are regional 


nodes, with Node 3’s functioning as the geographically defined regional gateways and 
Node 4’s as the sectional/functional gateways. The last node is the user node, which is 
identified as Node 5. The task of this thesis is to evaluate the effort needed to extend the 
CMA architecture to a disconnected Node 5. 

The Node Connectivity (OV-2), as shown in figure 2, is a graphical representation 
of the relationship between the various CMA nodes. The primary focus for this 
engineering study, as indicated by the circle on figure 2, is in the relationship between the 
disconnected Node 5 and the existing Node 4. This narrows the focus and identifies the 
functional requirements and capabilities for a Node 5 vessel or user to be able to 
collaborate, define local UDAP, assess threats and submit maritime data/information to 


the Node 4 Gateway. 
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Figure 2. CMA Node Connectivity Diagram (OV-2). 

Source: CMA JCTD Interim Report on Architecture draft version 0.2 (2007) by David R. 
Reading [Reading, 2007]. This figure depicts an abstract model of the CMA nodes. The 
circle on the figure identifies the primary focus of this thesis as the relationship between 
the disconnected Node 5 and existing Node 4 interaction. 


2. Node 4 
A Node 4 participant is the gateway between the Node 5 entity and the CMA 
network. It provides connectivity between Node 5 and all other CMA nodes. Node 4 is 
capable of: 
* Collecting CMA data, including data from Node 5 and providing it to the 
CMA network 
¢ Fusing CMA and Node 5 maritime data/info, using existing CMA fusion 
capabilities 
¢ Assessing threats; alerts 


¢ Sharing threats & pictures; including providing the UDAP for Node 5 


3: Node 5 
A Node 5 participant is a disconnected user or vessel that does not have direct 
connection to the existing CMA network. There is no data fusion capability at Node 5. 
This node is limited to sending request for area information and receiving updates from 
Node 4. The key functional areas addressed by a Node 5 entity include: 
e Limited sensor data manually entered at an aperiodic rate 
e Provides input into CMA network via Node 4 connection 
e Receives guidance from CMA network regarding mission specific 


information via Node 4 


D. ASSUMPTIONS 


The following are the high level assumptions made during this evaluation effort. 
e CMA exists, policies and restrictions are in place, and Nodes | through 4 
are implemented and fully operational. 
e Node 4 has fusion and operational capabilities to enable disadvantaged 
node connection to the CMA. 
e The architecture is an open design to accommodate integration of other 


systems. 


e Technology and policy for information sharing, e.g., Multi-Level Security 


(MLS) and UDAP, exist and are implemented. 


E. OBJECTIVES 


The direction provided by the primary stakeholders in the form of a Statement of 
Work (SOW), encompasses four primary objectives: (1) Characterization of the Problem 
Space, (2) Functional Representation and Decomposition, (3) Analysis of Key 
Capabilities, and (4) Documentation. The specifics of each of these areas, as defined by 


the SOW, are as follows: 


1. Characterization of the Problem Space: identify current system and legacy 
deficiencies as well as constraints inherent in the operational environment in order 
to characterize, understand and bound the problem space. The project team 
identifies and translates the relevant CMA functions from the Fleet MDA Concept 
of Operations (CONOPS), National MDA CONOPS, and the CMA CONOPS 
into system engineering structures (“to be” concepts, data models, and 
architecture functions, requirements, solutions) necessary to develop the 
disconnected Node 5 concept. The project team evaluates the functions, 
requirements and architectures in support of the integration of CMA 


requirements. 


2. Functional Representation And Decomposition: represent the system concepts 
through functional description and decomposition as well as system architecting 
and simulation. Develop representations, models, and methods to express 
automated resource collaboration concepts and information sharing solutions in 
the context of the CMA architecture and domains. The project team will develop a 
system model and architecture to evaluate the performance of the proposed 
architecture. System architectures are organized into views consistent with the 


Department of Defense Architecture Framework (DoDAF). 


3. Analysis of Key Capabilities: the identification and evaluation of technologies 


and research areas is key to the integration of Node 5 into the CMA concept. 


4. Documentation: 

a. PROJECT REPORT — Includes Chapters 1-5 detailing the problem 
statement, needs analysis and requirements definition, value system 
design, design and analysis and recommendations. 

b. IN PROGRESS REVIEW (IPR) — Status review provided end of 
Quarter 2. 

c. FINAL PRESENTATION 


F. THESIS SUMMARY 


In the past three years, the concept of MDA has evolved from the idea generated 
in the form of a presidential directive, to Concept of Operations, to the inception of a 
technology demonstration. There are several documents and plans that have been written 
detailing the requirements, operational impacts and draft architecture. One area 
overlooked to date is the introduction of a non-CMA, disconnected vessel, i.e. a hospital 
ship or shipping vessel, into the MDA environment and enable it to be an active 
participant in the information exchange. This is the focus of the thesis, the extension of 


CMA to disconnected users or vessels. 


The basis for the processes implemented in the evaluation of this engineering task 
is a tailored systems engineering design process. This process was tailored to address the 
efforts required to perform the analysis and evaluation of the extended CMA (xCMA) 
project. The tailored process is shown in Figure 3. As depicted by the process flow, 
there are four main phases encompassing the engineering cycle; Needs Analysis & 
Requirements Definition, Value System Design, Design and Analysis, and Decision 


Making. 
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Figure 3. xCMA Engineering Process. This figure depicts the tailored systems 
engineering process used in this effort as well as the flow of this report. 


These engineering processes provide guidance and facilitate the engineering 
activities necessary to define the problem, perform design and analysis and support 
decision making. These efforts culminate in an analysis of alternatives and a 


recommendation focused on the extension of CMA to a disconnected vessel. 


The resulting recommendation indicates the Satellite Communications 
(SATCOM)-Single Board Computer (SBC) Alternative, as the preferred option for 
extending CMA to a disconnected node in support of humanitarian efforts. A satellite 
communications capability is used as the communications means for connecting to the 
CMA network. The information from the host system consisting of an SBC, 
modem/router, power supply, display, and input devices packaged in a ruggedized, 
transportable container is routed through the modulator demodulator (modem) and then 


transmitted by the satellite transmitter to the Node 4 satellite receiver. The information 


from Node 4 is transmitted by a satellite transmitter and received by the system satellite 
receiver and demodulated for processing by the host system Mobile Terminal Equipment 
(MTE). The Network Interface Card (NIC) provides the system with a unique hardware 
Media Access Control (MAC) address for system identification. A Commercial-Off- 
The-Shelf (COTS) Global Positioning System (GPS) receiver is used to provide system 


Position Location Information (PLI). 
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Il. NEEDS ANALYSIS AND REQUIREMENTS DEFINITION 


The first phase of the systems engineering process is the problem definition phase 
consisting of needs analysis and requirements definition. These efforts include literature 
review and stakeholder analyses and result in the generation of system level requirements 
consisting of derived and stakeholder requirements. See Figure 4 for a detailed 
illustration. The purpose of these activities are to accurately identify the problem, 
understand what the user wants and define value rankings of the system based on the user 
inputs. The problem definition phase begins with a primitive need statement. For this 
effort, the primitive need was derived from a combination of the Statement of Work and 


direction received from the stakeholders. The primitive need statement is as follows: 
“To facilitate Maritime Domain Awareness, disconnected nodes need to be 


integrated into the Comprehensive Maritime Awareness construct to share data 


in support of humanitarian operations ”’. 
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Figure 4. Needs Analysis and Requirements Definition Phase. 
The green square in the figure indicates the current position in the tailored engineering 
process. 


A. LITERATURE REVIEW 


In order to ensure a clear understanding of the problem and the evolution of 
MDA, an extensive literature search was required. This literature search includes, but was 
not limited to, information relating to MDA and CMA. The tight coupling of this 
engineering task, with the on-going CMA efforts, resulted in stakeholder identification of 
the key documents pertaining to CMA. This chapter identifies the evolution of the 
documents, provides a summary of each document and details the accomplishments and 


capability gaps. 


President George W. Bush’s 2004 presidential directive began an initiative to 
increase awareness of maritime domain activities. Achieving MDA helps ensure national 


maritime security and supports an open global economy, which depends heavily on 
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maritime commerce. To maintain operation of the maritime commerce and provide 
maritime security, “MDA depends upon unparalleled information sharing” [United States 


Department of Homeland Security, 2005]. 


MDA has evolved and been shaped by documents generated at the National, 
Department of Defense and the U.S. Navy levels. These documents represent the work 
products and activities that have immediate impact on the U.S. Navy’s effort to achieve 
MDA and include the National MDA CONOPS, Navy MDA Concept, Fleet MDA 
CONOPS, Navy MDA Architecture, Maritime Headquarters (MHQ) with Maritime 
Operations Center (MOC), CMA CONOPS and the CMA JCTD - Interim Report on 


Architecture. The interrelationships between these documents are illustrated in Figure 5. 


The initial efforts in defining MDA are contained in two presidential directives, 
the National Security Presidential Directive (NSPD) 41 and the Homeland Security 
Presidential Directive (HSPD) 13. Since their creation, there have been several activities 
at the National and Department of Defense (DOD) levels initiating U.S. Navy efforts in 
MDA. The U.S. Navy’s activities and work products were derived or influenced by 


visions, strategies, and plans from the National and DOD levels. 


The National Policy HSPD 14 generated the National Strategy for Maritime 
Security. From this directive, the National Plan to Achieve MDA and the National MDA 
CONOPS were generated. The National MDA CONOPS further drilled into the 
implementation perspective and eventually created the MDA Information Technology 
Investment Strategy Capabilities Based Assessment (CBA) Process [United States Navy, 
2007]. 
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Figure 5. U.S. Navy Development Flow. 

This figure shows the relationship between the U.S. Navy MDA documents. The dashed 
lines indicate the influential sources and the solid lines identify the originating 
documents. The yellow boxes represent the national documents. The blue boxes 
represent the U.S. Navy documents. The purple boxes represent the joint documents. 


The definition of MDA is “the effective understanding of anything associated 
with the global maritime domain that could impact the security, safety, economy, or 
environment” [United States Department of Homeland Security, 2005]. The maritime 
domain is defined as “all areas and things of, on, under, relating to, adjacent to, or 


bordering on a sea, ocean or other navigable waterway, including all maritime-related 
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activities, infrastructure, people, cargo, and vessels and other conveyances” [United 


States Department of Homeland Security, 2005]. 


At the DOD level, there are two primary documents, the Homeland Security, 
Major Combat Operation and Stability Deterrence and the National Command Element 
Protection. These documents were created by the Joint Operations Center (JOC) and the 


Joint Forces Command (JFC) [United States Navy, 2007]. 


With the visions, strategies, and plans from the National and DOD levels, the U.S. 
Navy has developed several documents that include the Navy Maritime Strategy, Navy 
Operations Concept, Navy MDA Concept, Fleet MDA CONOPS, Navy MDA 
Architecture, Capabilities Based Analysis Process, Navy MDA Investment Strategy, and 
Navy War Fighting Capabilities [United States Navy, 2007]. In addition, the CMA JCTD 
documents resulting from the technology demonstration efforts provided clarifying 


information to the Fleet MDA CONOPS. 


A synopsis of the core documents and the key information they contain are 


detailed below. 


1. Navy MDA Concept 


The NSPD 41 / HSPD (late 2004) directed the creation of the Maritime Security 
Policy Coordinating Committee (MSPCC) to oversee the development of the National 
Strategy for Maritime Security (NSMS). The MSPCC established the MDA 
Implementation Team to develop an interagency concept of operations and an 


interagency investment strategy. The conclusions are as follows; 


e Homeland security was heavily focused on internal U.S. government 


information and intelligence sharing 


e An international and interagency framework for maritime security 


would be required 


e The U.S. Navy must play a key role 
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The U.S. Navy MDA Concept recognized that achieving MDA requires 
collaboration among the different stakeholders. The U.S. recognized that achieving 
MDA requires an understanding of our international partners. That is, the U.S. must 
understand and acknowledge that international partners are focused on how to support 
legal activities, such as freedom of the seas, domestic / commercial security, energy 
security, and fisheries, as well as how to deter illegal activities, such as narco-trafficking, 
illegal immigration, piracy, smuggling, and environmental damage. On the home front, it 
must be recognized that both private sector and all levels of government agencies play an 
important role in the success of MDA. Supporting the needs and roles of each 
stakeholder allows all interested parties to work toward common objectives that foster a 


culture of trust and confidence to achieve MDA. 


The Navy MDA Concept identified gaps that the U.S. Navy must fill both 
internally and internationally. Internally, it is recognized that the U.S. Navy has limited 
capability in the collection and fusion of data. It is also recognized that the U.S. Navy 
only has a common operating picture at a localized, classified, tactical level and has a 
limited capability to develop a coherent picture of small craft in the littoral area of 
interest. Internationally, the U.S. Navy recognizes it must also address the shortcomings 


that prevent the collection and sharing of information across boundaries. 


The Federal Aviation Administration (FAA) / North American Aerospace 
Defense Command (NORAD) model is identified as a good case to help establish safety 
of flight and effect commercial efficiency across the world. There are two key attributes 


of this model that are of interest to the Navy MDA Concept; 


e The FAA/NORAD process is unclassified, which allows the sharing of 


information freely across boundaries 
e The FAA/NORAD model is not controlled by DOD 


The model seeks support and collaboration from DOD, which allows common 
goals to be accomplished while increasing the model’s capacity. The Navy MDA 
Concept relies on the FAA/NORAD model to help translate MDA requirements into 
reality. The unclassified data and information collection, correlation, and dissemination 


capability and capacity of the collaborating stakeholders enables the free flow of 
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information in support of collective security. This provides a strong incentive for 
additional partners to join in the MDA effort [United States Department of Homeland 
Security, 2007]. 


2. National MDA CONOPS 


The National MDA CONOPS was developed to execute the National Plan to 
Achieve Maritime Domain Awareness. The goals of this CONOPS are to facilitate the 
deterrence and prevention of hostile or illegal acts within the maritime domain and to 
enhance safety, security, economy and protect the environment. To accomplish these 
goals, the CONOPS created the following objectives: (1) Describe the problem, (2) 
Describe the interagency desired state of MDA, (3) Improve MDA planning and 
execution at all levels and (4) Identify MDA-related functions and desired MDA-related 
capabilities [United States Navy, 2007]. 


The scope of the National MDA CONOPS includes the stakeholders from the 
U.S. Federal Agencies within the Global Maritime Community of Interest (GMCOID), 
state and local agencies, private sector and international partners. It was developed to 
complement existing programs and initiatives that affect the maritime security and it 
identified key components for achieving MDA. The Global Maritime Intelligence (GMI) 
and Global Maritime Situational Analysis (GMSA) are identified as two of these key 
components. MDA is achieved through effective and efficient integration of GMI and 
GMSA (MDA = GMI + GMSA). To do so, the CONOPS recognizes the importance of 
the following; 


e Distinction of responsibilities of the maritime agencies developing 
GMI and the responsibilities of those maritime stakeholders providing 


GMSA 


e Interactive qualities of GMI and GMSA repeated throughout the 
CONOPS to emphasize the foundational dependence upon this 
partnership 


e Synergy between intelligence and situational awareness 
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The following are defined in response to the CONOPS objectives in an effort to 


meet the goals listed above. 


a. Problem Description: 


Intelligence and information are critical to the success of MDA and must 
be gathered and shared across numerous boundaries for the effective understanding of the 
maritime domain. There are obstacles that impede the ability to share intelligence and 
information that are necessary to achieve MDA. The National MDA CONOPS identifies 
these obstacles as follows [United States Navy, 2007]; 


e Ineffective database connections for analysis of information gaps or 


redundancies 


e Inability to create situational awareness due to ineffective area-target 


information fusion 
e Incompatible and proprietary operating systems and organizations 
e Lack of trusted partnerships for sharing of information and intelligence 
e Policy restrictions on sharing data due to organizational perception 


e Limited interagency | communications, connectivity, and 


interoperability 


e Limited interagency awareness of complementary mission 


b. Interagency Desired State of MDA 


The National MDA CONOPS envisions “an environment where federal, 
state, local, tribal, private sector and international partners embrace and achieve the 
common objective of obtaining and sharing information as a mechanism to increase 
safety, security and economic prosperity in the maritime domain and have the supporting 


architecture to do so” [United States Navy, 2007]. To reach this desired state, the MDA 
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environment depends on the ability to monitor activities; identify and detect anomalies; 
collect, fuse, and analyze data through the use of automated fusion and analysis tools. It 
also allows the operational decision makers to effectively engage and defeat anticipated 


threats and meet the MDA Essential Task List from the MDA Plan. 


c. Improve MDA Planning and Execution [United States Navy, 
2007] 


The National MDA CONOPS addressed the processes required to achieve 
the desired MDA state. These processes included collection, fusion, analysis and 
understanding of data, dissemination, and archiving and maintaining discoverable 
information. Improving planning and execution in order to achieve the desired MDA 
state at all levels involves the implementation and adherence to these processes. The 
collection process involves gathering data and information from any pertinent source and 
method and requires cooperation between stakeholders of GMI and GMSA. The fusion 
process was defined as the activity of association, combination, and conversion of data or 
information into useable knowledge for the decision maker. This process was defined as 
critical when data or information examination was required for the detection of activities 
of interest with respect to operating patterns, anomalies, capability, and intent. The 
dissemination process was defined as “providing the right information to the right users” 
[United States Navy, 2007]. In the context of MDA, the dissemination process must 
provide relevant data, products, alerts, and warnings to the decision makers, analysts, and 
responders within the GMCOI. The archival and maintenance of MDA data and 
information was identified as essential for an effective MDA. Retention and retrieval of 
historic data was identified as a critical link for continuity of data and information used 


for enhanced operational capability. 


d. Parsing the Domain [United States Navy, 2007] 


The National Plan to Achieve MDA identified a requirement to 
“persistently monitor vessels and craft, cargo, vessel crews and passengers, and all 


identified areas of interest in the global maritime domain” [United States Navy, 2007]. 
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This desired operational state identified a requirement for extensive resources. To 
maximize the limited resources, the CONOPS envisioned an ability to divide and 
organize the maritime domain in such a way that allowed the prioritization of assigned 
resources. An analysis of the complete supply chain of events was identified as a way to 


gain a better understanding of area of interest. 


e. Levels of Awareness 


The National MDA CONOPS determined the prioritization of MDA 
capabilities and needs required parsing the MDA domain and establishing the level of 
awareness for each Area of Interest (AOI), its associated processes, and its subject 
category [United States Navy, 2007]. The levels of awareness were categorized into 
general (level 3), specific (level 2), and detailed (level 1). The general level of awareness 
contained generalized knowledge of patterns of migration, travel, and work in the 
maritime domain. The specific level of awareness included specific platforms, their 
operators, and companies working in the area of interest. The detailed level of awareness 
included actual information at an individual level. This covered the individual passenger, 


crew, and worker area of interest [United States Navy, 2007]. 


f Information Architecture 


The National MDA CONOPS called for a net-centric architecture robust 
enough to provide the required environment for secure, collaborative, information- 
sharing. The CONOPS envisioned an information architecture that allowed data 
providers to expose data for consumers to locate and retrieve. Furthermore, the data was 
expected to flow through the enterprise’s multi-level protocols and classifications with 
automated sanitization. The ultimate desired state of the user was identified as the ability 
to create a User Defined Operational Picture (UDOP) via a Services-Oriented 


Architecture (SOA) [United States Navy, 2007]. 
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3. Concept of Operations for Fleet Maritime Domain Awareness (Fleet 
MDA CONOPS) 


The Fleet MDA CONOPS was developed by the U.S. Navy and approved for use 
on 13 March 2007 [United States Navy, 2007]. It provided a foundation for the U.S. 
Navy commanders to build and achieve MDA. This foundation provided the necessary 
background to understand the fleet’s role in MDA and how it related to other entities 
including the U.S. Navy and interagency programs and directives. The Fleet MDA 
CONOPS focused primarily on the operational level of warfare [United States Navy, 
2007]. 


The Fleet MDA CONOPS defined MDA one level down from the Navy MDA 
Concepts and National MDA CONOPS, integrated standardized MDA-related processes 
and mechanisms into Fleet operations and guided the development of a U.S. Navy 
architecture supporting MDA. This Fleet MDA CONOPS was intended to help the U.S. 
Navy in fulfilling its roles and responsibilities as directed in the National Strategy for 


Maritime Security and its supporting plans” [United States Navy, 2007]. 


The Fleet MDA CONOPS addressed how MDA was enabled by the use of 
maritime intelligence as envisioned by the Global Maritime Intelligence Integration 
(GMII) Plan and the National Strategy for Maritime Security. It also stated that effective 
decision making is the result of an enabled MDA environment in accordance with the 
Maritime Operational Threat Response Plan (MOTR) and in support of all U.S. Navy 
missions” [United States Navy, 2007]. 


The primary purpose of the Fleet MDA CONOPS was to provide the fleet with an 
understanding of MDA and to describe the processes and mechanisms that enabled the 
U.S. Navy to accomplish missions. The CONOPS served as a basis for future U.S. Navy 
capability investment decisions, and influenced MDA development to meet current and 
future U.S. Navy needs. The following sections list the capability gaps, assumptions, 
restraints and constraints, operating environment, MDA fleet deployment and tasks and 
Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and 


Facilities (DOTMLPF) items identified in this document. 
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Warfighting Capability Gaps 


The following user inputs were used to derive the warfighting capability 


gaps [United States Navy, 2007]: 


Lack of net assessment, fusion, and collaboration tools 
Lack of cross domain solutions for information sharing 


Lack of maritime information gathering and collection within U.S. 


Navy areas of interest 


Lack of communication system training 


Assumptions and Constraints 


The Fleet MDA CONOPS addressed the assumptions, restraints, and 


constraints to ensure that there was an understanding within the U.S. Navy MDA 


organization. The assumptions included the following [United States Navy, 2007]: 


The National CONOPS for MDA will be approved 
The Navy MDA concept will be approved 
MHQ w/MOC will exist as the principal operational-level command 


and control node for the U.S. Navy 


MHQ w/MOC will be the primary operational-level net assessment 


center for MDA within the U.S. Navy 


The National Maritime Intelligence Center (NMIC) will serve as the 
Center Of Excellence (COE) for all-source maritime intelligence 


fusion within the GMCOI 


Technology and National DOD policy for information sharing, e.g., 
MLS and UDOP, will be developed and implemented within the 
Future Years Defense Program (FYDP) to support fleet information 


sharing requirements 
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e The MDA data strategy Community Of Interest (COI) will develop 
common data standards for MDA information to be shared across 


multiple security levels and network enclaves 


e Engagement with US, allied, and partner nations, Other Government 
Agencies, Non-Governmental Organizations, and private industry is 


necessary to develop MDA 


The restraints identified the scope of the U.S. Navy’s contribution. The 
U.S. Navy supported initiatives for expanded reporting requirements for vessels and 
cargo. It was governed by maritime strategy and was limited to areas where naval forces 


operate [United States Navy, 2007]. 


The constraints included the focus on U.S. Navy capabilities to be made 
available within Future Year’s Development Program (~2014). The Fleet MDA 
CONOPS identifies U.S. Navy challenges to achieve MDA. These challenges included 
sharing of data and information within the global maritime domain, handling, analyzing, 
releasing, and disseminating data from multiple sources, operating in a low bandwidth 
environment, and adhering to different laws, policies, regulations, and guidance [United 


States Navy, 2007]. 


c Operating Environment 


The Fleet MDA CONOPS addressed two types of operational 
environments; the physical setting and the associated information classification layers. 
The physical setting covered the U.S. Navy’s primary operational area, “blue water,” and 
the less common environments such as “green water” (non-combatant evacuation 
operations) and, “brown water” (riverine operations) [United States 2007]. The 
information classification layers identified the U.S. Navy’s focus on overcoming the 
challenges of operating in an environment with multiple collaborators and different levels 


of security access. 
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d. MDA Capability Deployment 


A key focus of the Fleet MDA CONOPS was the MDA capability 
deployment. The CONOPS identified the U.S. Navy’s contribution at three levels; (1) 
tactical, (2) operational, and (3) strategic. At the tactical level, the U.S. Navy collected 
and shared information. At the operational level, the U.S. Navy participated in creating a 
synergy between operations and intelligence to help create regional maritime situation 
awareness. At the strategic level, the Office of Naval Intelligence collaborated with the 
larger GMCOI Intelligence Enterprise to develop maritime intelligence and threat 


awareness [United States Navy, 2007].. 


The CONOPS identified five key information exchange ingredients for 
achieving MDA. These ingredients included: Location and Tracking Information, 
Contextual Information, Reference Information, Trend Analysis, and Intelligence [United 
States Navy, 2007]. It also addressed the integration of MDA requirements into existing 
or future systems and structures. Two key initiatives, Automatic Identification System 
(AIS) and Long Range Identification and Tracking (LRIT) system, incorporated 
important capabilities into the MDA. The AIS was identified as a maritime transponder 
for all vessels 300 gross tons or greater. The LRIT, mandated by the International 
Maritime Organization as part of the Safety of Life at Sea Convention, was identified as a 
requirement to provide the ship’s identity and time stamped location [United States Navy, 


2007]. 


e. Fleet MDA Tasks 


To address the fleet MDA requirements, the Fleet MDA CONOPS derived 
a set of twelve tasks from the Universal Navy Task List. These tasks were applicable to 
the commanders at the strategic, operational, and tactical levels. The derived tasks were 


identified as follows [United States Navy, 2007]: 


e Direct operational intelligence activities 


e Process and exploit collected operational information 
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e Produce operational intelligence and prepare intelligence products 
e Disseminate and integrate operational intelligence 

e Evaluate intelligence activities in the joint operations area (JOA) 

e Assess the operational situation 

e Develop a shared understanding of the situation 

e Acquire and communicate operational-level information and status 
e Collect and share operational information 

e Prepare plans and orders 

e Command subordinate operational forces 


e Coordinate and integrate joint/multinational and _ interagency 
cooperation 


Along with the twelve tasks, the Fleet MDA CONOPS identified the 
responsible entities at each of the requirement levels. At the strategic level, NMIC was 
identified as responsible for conducting maritime intelligence activities, integrating and 
fusing enterprise intelligence, supporting the operational and tactical requirements in the 
maritime domain. At the operational level, the MHQ was identified as responsible for 
directing the operational intelligence activities and commanding assigned forces. The 
activities included “indications and warning, situational awareness, target development, 
collection management, all-source threat analysis, and assessment reporting for 
operational planning and execution” [United States Navy, 2007]. At the tactical level, 
Commander Task Forces, Commander Task Groups, and Commander Task Units were 
identified as responsible for directing the tactical and operational intelligence activities 
specific to mission and operations. The tasks included classification, identification, and 


engagement areas [United States Navy, 2007]. 


Along with the fleet MDA tasks and responsible entities, the Fleet MDA 
CONOPS identified “processes” as a key ingredient necessary for successful operational 
intelligence activities for MDA. The processes used in the MDA life cycle include five 
phases [United States Navy, 2007]: 


e Intelligence planning and direction 


e Collection 


2D 


e Processing/Exploitation, i.e., process and exploit collected operational 


information 


e Analysis/Production/Dissemination, i.e., produce operational intelligence 


and prepare intelligence products 
e Assessment/Feedback, 1.e., evaluate intelligence activities in the JOA 


These phases are the foundation for day-to-day activities which ensures 
the maritime planning process mirrors the joint planning process, develops the MHQ 


commander’s intent, turns it into an executable plan, and tasks tactical forces. 


f Validation Requirements 


To address the validity of the MDA requirements, experiments, exercises, 
modeling and simulation (M&S), war gaming, workshops, seminars, and rock drills have 
been identified. To effectively prepare and conduct any requirements validation, the 
Fleet MDA CONOPS identified analytical questions that needed to be asked in order to 
gain relevant measures of effectiveness. Along with the analytical questions, the 
CONOPS also identified an analysis plan focused on workshops, wargames, and 
exercises. To effectively measure the analysis, the CONOPS identified Measures of 
Effectiveness (MOE) and Measures of Performance (MOP). In addition to the MOEs and 
MOPs, an Experimental Campaign Plan (ECP) was developed to help guide the 
requirements validation [United States Navy, 2007]. 


4. DOTMLPF 


The Fleet MDA CONOPS also addressed the DOTMLPF implications. Under 
doctrine, due to the nature of MDA, the CONOPS identified a shift from an individual to 
an integrated operational environment. This requires a development of doctrine and 


policy that includes: 


e Roles, Mission, and the GMSA task 
e Enterprise hubs 
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e Information sharing policies 
e Protocols with non-DOD partners 
e Revised foreign disclosure policies to facilitate the time sensitive nature of 


maritime areas of interest 


For the organizational focus, policies were required to help define and facilitate 
the inter-agency relationship among the members of the GMCOI. These included 
stakeholders at the local, state, regional, national, and international levels. For training, 
the CONOPS called for effective and efficient training at all levels which included 
individual skills, unit and composite group training. The training was identified to 
include live, virtual environment that involves real-world complexity in against a range 
of postulated threats. For the materiel solutions, alternatives are addressed to ensure 
effective future analysis. For the leadership area, the CONOPS identified a requirement 
to bring all stakeholders together to ensure trust, confidence, effective and efficient 
training, and lessons learned. For personnel, a detailed manpower assessment was 
required to effectively implement the Fleet MDA CONOPS. The CONOPS identified 
required training facilities for each participating organization. The CONOPS identified 
that there were no common operating processes, systems or linkages to the GMSA 
enterprise hubs. Therefore, each participating organization must use existing facilities to 


satisfy the MDA requirements for the near term [United States Navy, 2007]. 


5. CMA JCTD CONOPS 


The CMA JCTD CONOPS was generated under the efforts of the CMA JCTD 
which was focused on improvement of MDA through the demonstration of interagency 
and international information exchange. The goals of the CONOPS were to address the 
identification gaps through the effective and efficient prioritization of maritime threats 


and to enable proper allocation of security resources in the maritime environment. 


The U.S. Pacific Command (USPACOM) and Department of State (DoS) took 
steps in developing a multinational maritime security framework in March 2004. This 
collaboration resulted in a multilateral maritime security framework in the Asia-Pacific 


region. This effort was designed to offset risks posed by transnational threats including 
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“terrorism, trafficking in humans and drugs, movement of illicit cargo, and piracy” 
[CMA Architecture Team, 2007]. Partnering with willing nations moves the participating 
stakeholders toward MDA capability “through unity of effort to identify, monitor, and 
intercept transnational maritime threats consistent with existing international and 


domestic laws” [CMA Architecture Team, 2007]. 


To move one step closer to achieving MDA capability, the Republic of Singapore 
initiated a proposal for a joint effort with the U.S. to establish a CMA JCTD. This JCTD 
refines the goals and objectives identified in the National Strategy for Maritime Security, 
the GMII Plan, and the NSPD 41 / HSPD 13 Presidential Directive Security Policy 
[CMA Architecture Team, 2007]. 


In the summer of 2005, USPACOM, USNORTHCOM, and USEUCOM initiated 
a joint collaborative effort to develop the CMA JCTD capability. This JCTD was 
planned to accomplish MDA in three spirals. Spiral I focuses on the establishment of 
baseline information exchange in the coalition environment with stakeholder 
participation from the Republic of Singapore, USPACOM Pacific Fleet Command 
(COMPACFLT), and maritime analysts. Spiral II focuses on the internal U.S. 
interagency maritime information exchange and Spiral III focuses on implementing net- 
centric information management capability and demonstrating products relating to the 


MDA COI [CMA Architecture Team, 2007]. 


a. Operational Environment 


Requirements have been established to integrate information from the 
DOD, U.S. Coast Guard, Coalition/Allied forces and commercial maritime entities. From 
these sources disparate, tracking and other types of informational data must be integrated 


into a UDAP, which can be tailored for situation awareness. 


There were three operational concerns identified in maritime tracking. 
The concerns were as follows: 


e AnMLS solution must be identified for data sharing 
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e The warfighter’s systems do not have the capability required to 
integrate data from disparate sources 

e There is no single organization that can effectively coordinate 
Continent United States (CONUS) and Global requirements 
necessary for MDA 

The concerns regarding the integration of MDA are part of a larger 
problem the warfighters have with Command, Control, Communications, Computers, 
Intelligence, Surveillance, and Reconnaissance (C4ISR). A requirement was identified to 
provide an MDA capability to automatically detect, track and identify any movement of 
vessels in the assigned area of responsibility. This information was identified as a support 
for Command and Control (C2) decision-making. 

The gathered MDA information must be consolidated, disseminated and 
displayed in a tailored presentation. “The intent of CMA is to highlight threat 
information to maritime analysts as soon as possible, thereby increasing reaction time and 
providing greater opportunity to monitor and/or interdict these threats at greater 


distances” [United States Navy, 2007]. 


6. CMA JCTD-Interim Report on Architecture Version 0.2 


The CMA JCTD Interim Report on Architecture was a key document 
summarizing the work done to date by the CMA Architecture team. This document not 
only outlined the work products that were currently available but also included a section 
that provided an assessment of the current architecture and the way ahead. The following 
is a synopsis of the processes, tools, architecture and implementation guidance detailed in 


this document. 


a. CMA Business Processes 


As a result of the second workshop seven CMA business processes have 
been defined. These processes were also modeled with the Universal Modeling 
Language (UML) 2.0. The business processes consist of the following: 

e A User Defined Subscription 
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e First Hand Reporting 

e Threat Identification and Prioritization 

e Data/Information Sharing 

e New Information Source or Capability Incorporation 
e Security Auditing 


e Continuous Improvement 


b. Network Architecture 


As discussed in the CMA JCTD CONOPS, CMA uses the Combined 
Enterprise Regional Information Exchange System (CENTRIXS) network structure to 
share information with international partners. The software was based on a SOA and 
utilized both collaboration and integration tool sets. CMA utilized existing networks with 


tailorable information flows to exchange information at the appropriate security levels. 


c. CMA Core Collaborative Tool Sets 


The CMA core collaborative tool sets included email, chat and web 
services. The DOD and Services Defense Planning Guidance identified these tool sets as 
“required technology”. Other capabilities such as voice over Internet Protocol (IP) and 
video teleconference may be used in the future but are currently unavailable due to the 
bandwidth limitation of CENTRIXS. The CMA Enterprise Service also provided other 
services, which included mapping, notification, information assurance management, and 


authentication and authorization services. 


B. DERIVED REQUIREMENTS 


At the conclusion of the literature review, a list of requirements relevant to the 
extension of CMA was identified. Table 1 provides a consolidated listing of these 
requirements. Each requirement is listed beneath the document that it was derived from 
and given a reference number that is used in the traceability matrix discussed in the 


System Requirements discussion below. 
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Table 1. 


Derived Requirements 





Document 





Reference 
Number 


Derived Requirement 





National CONOPS to Achieve Maritime Domain Awareness. The system shall: 





Provide a secure, collaborative, information-sharing environment and 
unprecedented access to decision-quality information. A fundamental 
attribute of a net-centric environment is the ability for any consumer of 


information to get the information that is needed, when it is needed 


Provide pertinent data, products, alerts, and warnings to support decision 


makers, analysts, and responders within the GMCOI 





Provide the necessary level of awareness to the end-users for information 


about specific MDA pillars 





Provide a multi-level security and access structure as appropriate, tailored 
to enable users to pull appropriate information and data from the network, 


and to receive alerts and warnings pushed from the network to users 


Grant user access and provide data and services control based on roles, 


responsibilities and authorities within the multi-level security enterprise 








Provide a user defined awareness picture (UDAP). The UDAP will 
provide a shared display of friendly, enemy/suspect, and neutral tracks on 
a map with applicable geographically referenced overlays and data 
enhancements. The UDAP environment may include distributed data 
processing, data exchange, collaboration tools, and communications 
capabilities. The UDAP may include information relevant to the tactical 
and strategic level of command. This includes, but is not limited to, 
geographic information systems data, assets, activities and elements, 
planning data, readiness data, intelligence, reconnaissance and 


surveillance data, imagery, and environmental data 





a1 








Document 





Reference 
Number 





Derived Requirement 





Fleet CONOPS for Maritime Domain Awareness. The system shall: 





Provide flexible, scalable, and tailorable techniques, processes, and 


procedures that can be adapted rapidly and securely 





Provide reliable communications between, and among, nodes in the MDA 


network 





10. 


Implement a service oriented architecture (SOA) that will provide multi- 
level security, information assurance, storage, and performance 
management for a robust recovery capability. The architecture will allow 
appropriate information exchange transparency between non-classified, 
classified and unclassified domains, as well as across numerous 
contributing agencies. An SOA will enable the MOC and fleet units to 
publish and subscribe to common-source data in order to develop a 
common understanding through a UDAP. It is a picture of the current 
state of the maritime environment with available layers of information 
that includes information specific to the vessel such as _ history, 


destination, crew, cargo, affiliation, etc 


Provide effective and efficient training across the spectrum of activities 


from individual skills development, to unit and composite group training 





CMA Implementing Directive (JROC Approved). The system shall: 

















Tl Provide an SOA based operational capability to perform MDA functions 
CMA CONOPS The system shall: 
Provide the capability to rapidly assemble a theater wide maritime picture 
‘ey and disseminate selected track information to international and 





interagency partners through classified and unclassified networks using 


appropriate security guards 
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Document 





Reference 
Number 


Derived Requirement 





13, 


14. 


Use, develop or modify the automated decision aid to display information 
in a UDAP environment and leverage service oriented architecture to 
manage data, enable data exchanges and provide CMA participants with 


the means to display data sets meeting their respective requirements 


Include e-mail, chat and web services as its core tools. Voice over IP 
(VoIP) and video teleconference capabilities are envisioned to be part of 


the CMA capability 





15. 


Develop a service oriented architecture that will fuse this information and 
integrate it with automated vessel tracking capabilities to develop a 


comprehensive maritime picture 





16. 


Provide an open-system architecture that facilitates accurate, timely and 
inter-operable information and intelligence sharing and promotes 


collaboration among the GMCOI 





ee 


Consolidate unclassified data for CMA through the use of local, 
commercial, and other readily available source information. Data, as 
appropriate, will be consolidated and passed to higher classified systems. 
Either of these can make the originally unclassified data classified. As 
such, this newly formatted data is passed through a Multi-Level Security 


Guard onto the appropriate servers and databases 








18. 





Provide depot level maintenance 
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Document 





Reference 


Number Derived Requirement 





Provide security requirements will comply with those standards delineated 
in appropriate DoD Operational Security (OPSEC) Instructions. Security 
measures will support the five fundamental information assurance 
19. elements (confidentiality, integrity, availability, authentication, and non- 
repudiation) and will define how CMA manages, protects, and distributes 
sensitive information. System accreditation will be the responsibility of 


the Designated Approval Authority (DAA) 





56 Provide warfighters the capability to accurately display all available 


military and commercial maritime data on the UDAP 








Enhance the value of existing systems by allowing their Position Location 
3 Information (PLI) data to be displayed on the UDAP and providing a 
mechanism for multi-source correlation, providing increased situation 


awareness 








Source: Documents identified by stakeholders as key to this thesis were reviewed and the 


derived requirements were compiled. 


C. STAKEHOLDER ANALYSIS 


Stakeholder Analysis was performed to determine and validate the people relevant 
to the problem, and to capture their requirements for the system. The stakeholders, or 
customers, have significant interest and/or investment in the problem and its solution. 
The primary customers for the xCMA effort were identified as the MDA Project Deputy 
and Transition Manager, PEO-C4I and his team. Mr. John M. Green and Dr. Rachel 
Goshorn, the advisors and coordinators for this effort, and were also identified as 
stakeholders. CMA was based on the MDA concepts and policies. Due to the primary 
focus for this effort being on CMA, the stakeholders were limited to those listed above to 


ensure that guidance received is directly applicable to the problem at hand. 
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Due to the parallel development efforts of the CMA JCTD, stakeholder inputs and 
communications were under the direction of Dr. Rachel Goshorn and consisted of limited 
interviews and email exchanges. The requirements received from the stakeholders were 


compiled and have been included in Table 2. 


Table 2. Stakeholder Requirements 

















Document 
Se Stakeholder Requirement 
Number 
Statement of Work. The system shall: 
22. Extend Comprehensive Maritime Awareness (CMA) to disconnected nodes 


to facilitate continued information sharing 





23. Operate within the size, power and weight constraints similar to small 


vessels and assumes max distance to node 4 of 30 nm 





Stakeholder Analysis. The system shall: 








24. Handle a minimum Bandwidth of 128 Kbps 











Source: Statement of Work and stakeholder feedback via interviews and email exchange 


established this list of stakeholder requirements. 


D. SYSTEM REQUIREMENTS 


The culmination of the Needs Analysis and Requirements Definition activities are 
the system requirements for the xCMA system. These are comprised of the derived 
requirements identified in the literature review activities and the stakeholder requirements 


provided by the stakeholder. These requirements are listed in Table 3. 
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Table 3. System Requirements 


xCMA System Requirements 


Defining Documents 


Provide secure connection of Node 5 to CMA Node 4 


Maritime Domain Awareness (1- 


Fleet CONOPS for Maritime 


(7-10) 


Domain Awareness 


CMA Implementing Directive 


(JROC Approved) (11) 


CMA CONOPS (12-21) 


SOW (22-23) 


Stakeholder Communications 





Provide unclassified warnings and alerts 





Provide unclassified UDAP 





Provide access to all required info 





Provide access to web services 





Provide capability to store data and info 





Provide intuitive human system interface 


13,20 





Provide scalable system - maximize interoperability 


13,24 





Provide flexible system - allow user display customization 


13 





Provide accurate data and info 


16, 20, 24 





Provide accurate local data and info 


13,16,17,20 





Provide a portable system 





Provide reliable system 





Provide flexible system operator training 





Minimum Bandwidth = 128 Kbps 





Connect with CMA 





Receive data and information 


12,16,17,21 





Transmit data and information 


12,13,14,16 





Manage data and information 


13,19 





Provide unclassified collaboration 


14,16 





Provide open architecture design 





Provide plug and play interface 





Provide Graphical User Interface (GUI) 


13,20,21 





Provide Computer Based Training (CBT) 





Provide depot only maintenance paradigm 


18 





Provide Ao = 0.9 


18 





Provide MTBF = 1500 hrs 


18 





Operating radius = 30 nautical miles 

















Source: These xCMA requirements were pulled from key documents identified by the 
stakeholders. The left column is a list of all the requirements. The columns to the right 
each identifies a specific document. The numbers in each of these columns corresponds 


to a requirement. 
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Hil. VALUE SYSTEM DESIGN 


The next phase in the tailored systems engineering process is value system design. 
This phase consisted of an Input/Output Analysis, Functional Analysis, Functional 
Hierarchy and Quality Functional Deployment (QFD) analysis. See Figure 6 for a 
detailed illustration. The purpose of this phase in the systems engineering process was to 
identify a set of objectives and evaluation measures. In addition, multi-dimensional 
attributes and decision criteria were developed to provide guidance during the remainder 
of the system engineering process and to ensure selection of the most appropriate system. 

This phase begins with the identification of the input, output and functional 
requirements and functional interaction between Node 4 and Node 5. It then proceeds 
with the identification of objectives and evaluation measures in the form of a functional 
hierarchy. At this point an effective need statement was defined based on the needs 
analysis. Finally, QFD analysis was applied to promote integration of organizational 


functions and to facilitate responsiveness to the system and stakeholder requirements. 
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Figure 6. Value System Design Phase. 

This drawing shows the relationship of the Value System Design Phase to the other 
activities in the system engineering process. The green square in the figure indicates the 
current position in the tailored engineering process. 


A. INPUT-OUTPUT ANALYSIS 


In addition to understanding the problem and the customer’s needs, it was 
necessary to adequately determine the boundary conditions and scope of the problem. To 
facilitate this, the xCMA system was evaluated from a component and structural 
perspective. This resulted in the identification of two nodes of interest, the gateway node 
(Node 4) and the disconnected node (Node 5), as well as the overarching CMA 
Architecture. These are key elements in defining the core of the xCMA system and 


provided the boundaries and constraints under which it must function. 


The scope of this effort is limited to a point-to-point connection between Node 4 
and a disconnected Node 5. A system context diagram was generated detailing the inputs 


and outputs of the overall system and is shown in Figure 7. 
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Node 4 Subscription Information | | 
COI Information . | 
Warnings & Alerts : | 


Bandwidth Allocation | 





Geo-location Information 


GPS 
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Communications 


Figure 7. xCMA Context Diagram 
This is the Context Diagram, from the Node 5 


UDAP . 
Validated Authentication ; Cyr ICRA 



























Web Services Information 


Node 4 
Position Information , 


Own Ship Position , | 
Authentication Request _, 
AO Scalable Bandwidth . 











Users 


perspective, of the xCMA system. It 


depicts the information flow between the system and the Node 4 Gateway. 


Definitions of the inputs/outputs of the xCMA system are shown in Figure 8, the 


Operational Node Connectivity. Each of the identified inputs and outputs are detailed 


below for clarification. 
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Subscription Information (1) 
Web Services Information (2) 


COl Information (3) 
Warnings and Alerts (4) 
Local Awareness (5) 


Authentication Request (6) 


Geolocation Information (7) 
UDAP (8) 
Bandwidth Allocation (9) 
Vessel Information (10) 
CMA Information (11) 


Scalable Bandwidth (12) 
ValidatedAuthentication (13) 
Own Ship Position (14) 





Figure 8. Operational Node Connectivity (OV-2). 
This diagram details the input and output information and the directional flow from Node 
4 and Node 5. 


1. Subscription Information: Subscription Information defined as an input and output to 
the proposed system. The local Node 5 user enters relevant subscription information 
(input) based on the required data. The system sends the subscription information to 


Node 4 for processing (output). 


2. Web Services Information: Web Services Information provides access to a web 
browser, chat functions, e-mail and collaboration tools for the disconnected Node 5. Web 
Services Information defined as both an input and output to the proposed system since the 


flow of information is bi-directional to and from Node 5. 


3. COI Information: COI Information was defined as an input to the proposed system 
and was provided in the form of a web based data repository by Node 4. The proposed 
system has the capability to store and access this database locally with updates being 


provided through the Node 4 gateway. 
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4. Warnings & Alerts: Warnings and Alerts were defined as an input and output of the 
proposed system. The proposed system shall be capable of receiving Warnings and 
Alerts via Node 4 (input) to be provided to Node 5. Node 5 sends locally generated 
Warnings and Alerts (output) to Node 4 via the proposed system. 


5. Local Awareness: Local Awareness was defined as an input and output to the 
proposed system and defined as being provided by Node 5. Node 5 inputs any Local 


Awareness it has from onboard sensors which will be provided to Node 4 (output). 


6. Authentication Request: The Authentication Request was defined as an input to the 
proposed system and was tied to the system’s physical location and Network Address. 
Some additional form of authentication was determined necessary to ensure the person 
accessing the CMA network was authorized to obtain CMA information. Additional 
authentication requirements were detailed in the Authentication Policy provided by the 


CMaA architecture. 


7. Geolocation Information: Geolocation was defined as the real-world geographic 
location of the connected system and an input to the proposed system. Geolocation 
Information provided automatically by the systems position location information 


capability. 


8. UDAP: The UDAP was defined as an output of the proposed system. The UDAP 
was also defined as an output to a display on the xCMA system. The UDAP, sent by 
Node 4, is dependent on the own ship position information, vessel information and user 


requirement. 
9. Bandwidth Allocation: Bandwidth Allocation was defined as an input to the 


proposed system and provided by Node 4. Allocation of bandwidth depends on the user 


requirements for information and urgency/priority of the needed information. 
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10. Vessel Information: Vessel information was an output of the proposed system. A 


Node 5 user inputs required data on his own vessel and send this information to Node 4. 


11. CMA Information: CMA Information was defined as an Input to the proposed 
system. CMA Information provided by Node 4 to the system consists of information 


fused and analyzed by the CMA architecture or Node 4. 


12. Scalable Bandwidth: Scalable Bandwidth was defined as an output of the proposed 
system and depends on the user requirements and priorities for receiving updated 


information. 


13. Validated Authentication: Validated authentication was defined as an output of the 
proposed system. The Node 5 user requests authentication as an input. The output of this 
request is the validated authentication. Without a valid authentication Node 5 is unable 


to connect to the CMA architecture. 


14. Own Ship Position: Own ship position was defined as an output of the proposed 


system and gives the geolocation information for the vessel. 


The value of the input-output analysis is in the big picture view of the system 
inputs and outputs and boundaries. It provides a succinct, singular view of the system 


interdependencies and provides insight into the development of the Functional Analysis. 


1. Functional Analysis 


A functional analysis was performed to understand the proposed system from a 
functional viewpoint. The functional description allows for the system to be designed 
independent of any specific technical solution. This facilitates the evaluation of all 
technical options prior to implementing a specific technical approach. A functional 
decomposition provides reasons for the different physical components or equipment 
selected to implement the system. Thinking of the system in functional terms provides a 


basis for developing innovative alternatives. 
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For the xCMA system, the high level functionality consists of three functions, 
Connect with CMA, Provide Collaboration, and Manage Information. The definitions of 


these functions are shown below. 


e 1.0 Connect with CMA — functionality involved with physically connecting 
the disconnected vessel with the Node 4 Functional Gateway, including 


locating and identifying the system. 


e 2.0 Provide Collaboration — bidirectional communication between the 
disconnected node, Node 5, and the Node 4 gateway. This includes sending, 
receiving and displaying all information including web services, UDAP, COI 


Database, etc. 


e 3.0 Manage Information — managing and handling of information local to the 
disconnected node. This includes data storage, and send, search and retrieval 


functionality. 


These functions are then further analyzed to detail the lower level subfunctions as 
part of the functional decomposition. This functional decomposition is detailed in Figure 


9 and a description of each function is listed in Table 4. 


43 


xCMA System 


















































1.0 Connect 2.0 Provide 3.0 Manage 
with CMA Collaboration Information 
TACHI 2.1 Receive 2.2 Send 2.3 Displa 3.1 Store 3.2 Purge 3.3 Access 
Network 1.2 Identify 1.3 Locate . ‘ : ; : play ; ; ' g ‘ : 
Connectivity Information Information Information Information Information Information 































































































































































































































































































2.1. 214 ‘ : : 
2.1.4 2.1.2 : : 2.1.5 2.1.6 Receive i q 2.3.3 Display 2.3.4 Display ; 

Receive Receive Ree Receive Receive CO! Web Services 23-1 Display: 2.3.2-Display Web Services Alerts & eo ene. 

4 Alerts & Archived Archived Info UDAP. : COl DB Info 
CMA Info Position Info ; DB Info Info Info Warnings 

Warnings Info 
2.2.1 Send 2.2.2 Send 2.2.3 Send 2.2.4 Send 2.2.5 Send ; 
Ownship Subscription Local Alerts & Web Services oa oe ee 
Info Info Awareness Warnings Info 
Figure 9. xCMA Functional Decomposition. 


This figure details the decomposed functions and sub-functions of the xCMA system as derived from the system requirements defined 
in the Problem Definition Phase. 


Assumptions: 
1. Node 5 stores 48 hours of data locally 
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Table 4. | xCMA Function and Sub-function Descriptions 
[Reference | Function ——«d SSCS aint SSCS 


Connect with CMA This category of functions includes the functionality involved with 
physically connecting the disconnected vessel with the Node 4 Functional 
Gateway, including locating and identifying the system and vessel. 


Archieve Network Connectivity This function represents the direct network connection, (RF, Satellite 
etc)from Node 4 and the xCMA system including the hardware 
connectivity, the handshaking and network negotiations. 


1.2 Identify This function represents the unique hardware identification of the xCMA\ 
system itself. For example, this may include the unique Media Access 
Control (MAC) address or on-chip hardware identification. 

1.3 


This function represents the ability of the xCMA system to obtain it's 
location via a global positioning system or equivalent. 


Provide Collaboration This category of functions includes bi-directional communication between 
the disconnected node, Node 5, and the Node 4 gateway. This includes 
sending, receiving and displaying all information including web services, 
UDAP , COI DB etc. 

Receive Information This function represents the ability of the system to receive all incoming 
CMA information or system operational inputs. Each of the following 
functions identify the category of information or data being received. This 
information includes:: 


This function represents the ability of the system to send relevent and 
required information or data. This information includes:: 


[eee function represents the ability of the system to display all CMA 
relevent information. This information includes:: 


Manage Information This function represents the ability of the system to retain and provide 
pe ene emiet  eestesesshassemolniomton 
a 

information. 


Purge Information This function represents the ability of the system to delete previously 
stored information, either based on a time dependent action or user 
request. 


3.3 Access Information This function represents the ability of the system to access previously 
stored information. 


3.3.1]Sort & Search Info This function represents the sort and search capability of the system that 
supports the ability to display archived information as requested by the 
user. 


3.3.2|Retrieve Info This function represents the ability of the system to retrieve the previously 
stored information. 
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The hierarchy of functions is generated from the functional decomposition. It starts with 
the effective need statement and supports decomposition of existing functions into subfunctions 
to provide a more accurate view of current functionality. This facilitates the identification of the 
objectives and evaluation measures for all lower level functions. These objectives and their 
corresponding evaluation measures are shown in Table 5. The sources of the values used in the 
evaluation measures were a combination of guidance from standards documents (i.e. Mean Time 
Between Failure (MTBF) = 1500 hours (hrs), MIL-PRF-28800F), similar functional systems, 
and expert knowledge. All system availability numbers assume that the network and all 
components of the system are fully functional. Therefore, the system availability of 100% for 
Receipt of Alerts & Warnings represents the expectation that all of these high priority alerts will 
be received when the xCMA system, Node 4 and the connecting network are fully functional. 
Data correctness refers to the format of the information received, sent and/or displayed. The 


Functional Hierarchy for the xCMA system is depicted in Figure 10. 


Finally functional flow block diagrams were developed to show the functional 
interactions and provide a better understanding of the system. These tools were utilized to 
collectively come to better understanding of the process required to extend CMA to a 
disconnected vessel. The flow diagram also identified those functional elements conducted in 
parallel, and those requiring feedback loops. During the analysis, the flow was reviewed to 
ensure that the process accurately represented the system that was being modeled. The 
functional flow block diagram is included in Appendix C and was useful in detailing system 


interaction and determining the functional relationships, redundancies and dependencies. 
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Table 5. © xCMA Function and Sub-function Objectives and Evaluation Measures 


Objectives Evaluation Measures 


1.1 Archieve Network Connectivity Establish and maintain connectivity Network Up Time = 95% 
MTBF = 1500 Hrs 


Identify Identification Accuracy=100% 


Locate Location Accuracy within +/- 10 m 


Reference 


1.2 
1.3 


aaa SSS SSS aaa 


BR 


2.1.1 


Receive Information a 

Receive CMA Info Increase Data Availability & Accuracy |Data Accuracy = 90%; AO=90% 

Receive Position Info Maximize Accuracy & Availability Accurate within +/- 10 m; Available 
95% 

Receive Alerts & Warnings Increase Data Availability & Priority A0=100% 


eceive Archived Info Maximize Data Availability A0=90% 
eceive COI DB Info Maximize Data Availability A0=90% 


Receive Web Services Info Increase Data Availability & Accuracy |Data Accuracy = 90%; A0=90% 


Send Information Lo 


2.2.1]Send Ownship Info Increase Data Correctness Probability that the Data is Correct 95% 
of the time 


Send Subscription Info Increase Data Correctness Probability that the Data is Correct 95% 

Send Local Awareness Increase Data Correctness Probability that the Data is Correct 95% 

Send Alerts & Warnings Probability that the Data is Correct 95% 
of the time 


Send Web Services Info Increase Data Correctness Probability that the Data is Correct 95% 
of the time 


Display to ae ee 
2.3.1]Display Archived Info Increase Data Correctness Probability that the Data is Correct 95% 
of the time 


Display UDAP Increase Data Correctness Probability that the Data is Correct 95% 

Display Web Services Info Increase Data Correctness Probability that the Data is Correct 95% 

Display Alerts & Warnings Probability that the Data is Correct 95% 
of the time 


Display COI DB Info Increase Data Correctness Probability that the Data is Correct 95% 
of the time 


2.1.2 


2.1.3 


2.1. 
2.1. 
2.1.6 


un 
ok ee) 


2 


2.2.2 


2:2:3 


2.2.4 


2.2.5 


N 


3 


2.3.2 


2.3.3 


2.3.4 


2.3.5 


Manage Information eee 


Store Information Maximize Mission Capacity Storage of nominal Mission Data=95% 


Purge Information Maximize Mission Capacity Storage of nominal Mission Data=95% 


3.3.1]/Sort & Search Info Minimize Data Access Time Data Access < 10s 


3.3.2|Retrieve Info Increase Data Availability & Accuracy |Data Access < 10s 


w 





N 
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Figure 10. 


This diagram shows the functions and sub-functions as defined in the functional decomposition and provided the identified objectives 














The CMA needs a robust, flexible, reliable, user-friendly, 
supportable system that receives, provides and displays 
relevant, timely situation awareness information to non- 
integrated vessels to facilitate the execution, control and 


assessment of humanitarian mission operations. 
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Top Level Hierarchy of Functions for the xCMA system. 


and evaluation measures. 
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In order to accurately capture the behavior and information flow through the xCMA 
system, Integration Definition for Function Modeling (IDEFO) was implemented. IDEFO is a 
common modeling technique, a tool to aid in the functional analysis and was used to create a 
model for the proposed black box system. The IDEFO model was used to show data flow, 
system control, and the functional flow of the proposed system to extend CMA to a disconnected 
Node 5. The model was created to provide a precise description of the proposed system and 
promote consistency in the terms being used and their interpretation. The IDEFO products 
developed in support of this effort are located in Appendix D. 

The IDEFO model consists of a hierarchical series of diagrams and text. The two primary 
components are the functions and data that inter-relates to those functions. The IDEFO model, in 
conjunction with the functional analysis, directly supported the generation of the Systems 
Communications Description System View (SV-2), which depicts pertinent information about 
communications systems, links and networks that support the xCMA systems. The SV-2 is one 
of several DoDAF products. The DoDAF is a tool that provides a common approach for 
describing, presenting, and integrating architectures. The product set describes a method of 
designing a system in terms of subcomponents, often referred to as building blocks, and detailing 
how they fit together. The SV-2 for the xCMA system is shown in Table 6. 

Decomposing these functions further, resulted in the identification of subcomponents of 
interest which include interfaces and entities that make up the system. These functions are 
grouped based on subcomponent functionality. This functionality, along with the interfaces 
between the xCMA system and system nodes, is captured in the Systems Interface Description 
(SV-1) depicted in Figure 11. This diagram shows system nodes and the sub-systems resident at 
these nodes that support the information sharing between the Node 4 gateway and the 
disconnected Node 5 vessel. To augment the functional flow, and detail the information between 
the Node 4 and Node 5 systems, the Operational Information Exchange Matrix (OV-3) was 
generated. This matrix, shown in Table 7, defines the triggering events and the priorities of the 


information exchanges required of the xCMA system. 
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SV-1: Systems Interface Description 


Figure 11. Systems Interface Description (SV-1). 
This diagram details the system interactions, at the functional component level, for the xCMA system. 
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Table 6. | Systems Communications Description (SV-2). 


‘ Sending Op Communication Links and Receiving Op 
Node 4 Radio Frequency (RF) Node 5 
Node 4 ; Node 5 
Web Services Information Se RF Wireless Network Node 4 


COI Information | 3 | ~~ Node4 | _sRF Wireless Network/SOA Node 5 


: Node 4 . Node 5 
Warnings & Alerts RF Wireless Network/SOA Node 4 
ae Node 4 . Node 5 
Authentication Request Le | ee RF Wireless Network Node 4 
; ; : Node 4 
Geolocation Information 7 Node 5 RF Wireless Network 
Node 4 . Node 5 
. ; . Node 5 
Bandwidth Allocation Node 4 RF Wireless Network 


Vessel Information RF Wireless Network/SOA Node 4 
CMA Information RF Wireless Network/SOA Node 5 

















Validated Authentication 13 Node 4 RF Wireless Network Node 5 
Own Ship Position 14 Node 5 RF Wireless Network/SOA Node 4 


The SV-2 Systems Communications Description table details need lines for the communication, the sending and receiving nodes, 
communication links and network links. 
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Table 7. 


Operational Information Exchange Matrix (OV-3). 


; Info Ex eke ; : ee Sending | Receiving Op 
puecapnen 1 Provide Collaboration Per Request Routine Node 4 Node 5 
Information 
Web Services ‘ : : Node 4 Node 5 
COI Information Provide Collaboration Node 5 

‘ . ; ‘ : Node 4 Node 5 
Warnings & Alerts Provide Collaboration Upon Receipt Node 4 
Authentication : : : Node 4 Node 5 


Gealecan o 7 Connect with CMA Daas Commecnan and Routine Node 5 Node 4 
Information Periodic 

; . : Node 4 Node 5 
UDAP . Provide Collaboration Upon Updates Routine Node 5 Node 4 
Pandyagia Connect with CMA Upon Connection Routine Ned Node 5 
Allocation 


Vessel Information Provide Collaboration Node 5 Node 4 


CMA Information 11 Provide Collaboration D pene osnestion ane Routine Bee Node 5 
Updates 

Scalable 12 Connect with CMA Upon Connection Routine Node 4 Node 5 

Bandwidth 

vacate ; 13 Provide Collaboration Per Request Immediate Neer Node 5 

Authentication 


Own Ship Position Provide Collaboration Node 5 Node 4 


The OV-3 is a DODAF product that provides information regarding need lines, mission scenario, trigger events, timeliness, sending 
and receiving nodes. 
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The output of the Needs Analysis, which consists of all work done up to this 
point, is the revised problem statement, or Effective Need statement. It is created through 
iteration, feedback, and creativity during the processes utilizing System Decomposition, 


Stakeholder Analysis, and Functional Analysis. This Effective Need is stated below: 


“The CMA needs a robust, flexible, reliable, user-friendly, supportable system that 
receives, provides and displays relevant, timely situation awareness information to 
non-integrated vessels to facilitate the execution, control, and assessment of 


humanitarian operations.” 


In addition, amplification of terms referenced are as follows: 


— Robust - graceful degradation; ability to connect and communicate with 
the CMA via Node 4 


— Flexible - plug and play capability, mission tailorable 

— Reliable-operational availability of 0.90 with MTBF of 1500 hours 
— User-friendly -automated and system-assisted help for user 

— Supportable -Depot level maintenance only 

— Relevant - user receives requested information 


— Timely-in sufficient time to be of value to the user 


B. VALUE SYSTEM DESIGN 
1. QFD 


The QFD model was used to enhance the xCMA traceability of customer’s high 
level needs to system functions and lower level attributes of potential system solutions. 
The QFD model facilitates the systems engineering decision making process through the 
scoring of the relationship strength between each requirement and attribute of the model 
and through the evaluation of the interaction for positive and negative impact among the 


model’s attributes. 
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In this study, three QFD models were used to focus on the relationship between 
customer requirements and system level requirements, system level requirements and 
functional requirements, and functional requirements and evaluation measures. Figure 12 


depicts these models graphically. 
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Figure 12. QFD models used in translating customer requirements into decision 
making attributes. 

This figure also shows the sources of information and flow with dependency of the QFD 
models. 

In this QFD analysis, the customer requirements and system level requirements 
are derived from the National CONOPS to Achieve MDA, Fleet CONOPS for MDA, 
CMA Implementation Directive, CMA CONOPS, SOW, and stakeholders. See Table 3 
in Chapter 1 for specific reference of each customer requirement. The functional 
requirements are derived from the functional analysis. The evaluation measures are 
derived from the value hierarchy analysis. 

In order to support the decision making process, the three QFD models were 
developed to methodically translate customer desires into quantifiable measures. The 


first translation starts with the customer requirements and system level requirements. This 
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analysis scores the relationship strength for the customer requirements with the system 
level requirements. Furthermore, the analysis evaluates the impact of interactions 
(positive, negative, neutral) within the system level requirements. The second translation 
uses the system level requirements to pair with the functional requirements. This analysis 
scores the relationship for the system level requirement and functional requirements. 
This analysis also evaluates the attribute interactions within the functional requirements. 
The third translation uses the functional requirements to bounce off the evaluation 
measures. This particular analysis scores the functional requirements with the evaluation 
measures. The analysis also evaluates the interaction within the evaluation measures. 


The QFD results are discussed in the sections below. 


Zz QFD with Customer Requirements and System Level Requirements 


The interactions of the system requirements in the Pareto chart in Figure 13 
indicate that an open architecture design, a plug and play interface, and graphical user 
interface have positive interaction with the core functions (connect, receive, transmit, 
display, and collaborate) in Node 5. Furthermore, maintaining a 0.90 operational 
availability and MTBF of 1500 hours have positive interaction with the core functions of 
Node 5 as well. 

The Pareto results also illustrate the influence of the customer requirements. The 
top 20% of the attributes of the xCMA QFD for customer requirements and system level 
requirements indicate that the following are most important: 


1. Displaying data and information from CMA Node 4 
2. Receive data and information from CMA Node 4 


3. Providing unclassified collaboration 
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Influence of Customer Requirements on System Level Requirements 
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Figure 13. Influence of Customer Requirements on System Level Requirements for 
xCMA. 

This Pareto chart helps identify the most important System Level attributes for decision 
making process. 


as QFD with System Level Requirements and Functional Requirements 


The interactions of the system functions and sub-functions indicate both negative 
and positive interactions. The negative interactions are seen in the areas pertaining to 
system bandwidth and throughput. These include components supporting network 
operations, display and system storage. The Node 4 and Node 5 connection has positive 
impact on the core functions (connect, receive, transmit, display, and collaborate) in 
Node 5. This is the case because this connection is required by the xCMA node. The 
Pareto diagram in Figure 14 provides results to illustrate the influence of the system level 
requirements on functional requirements. The top 20% of the attributes of the xCMA 
QFD for system level requirements and system functions and sub-functions indicate that 


connecting with Node 4, sending subscription, displaying MDA UDAP, displaying web 
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services, displaying warnings and alerts, and displaying COI information have the highest 


influence strength. 





Influence of System Level Requirements on System Functions and Sub-Functions 
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Figure 14. Influence of System Level Requirements on Functional Requirements for 


xCMA. 
This Pareto chart helps identify the most important attributes for decision making 
process. 


4. QFD with Functional Requirements and System Evaluation Measures 


The interactions of the evaluation measures indicate negative interactions with 
regards to storage bandwidth limitations and data sort, search and retrieve time. Positive 
interactions are also identified in geolocation data accuracy, geolocation data availability, 
CMA data retrieved accuracy, CMA data availability, incoming warnings and alerts 
accuracy, and incoming warnings and alerts availability. This is the case because the 
CMA data and warnings and alerts are pulled from Node 4, which are based on the own 


ship location data. 
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Figure 15 below provides Pareto results to further illustrate the influence of the 
functional requirements on the evaluation measures. The top 20% of the attributes based 
on relationship strength from the xCMA QFD for functional requirements and evaluation 
measures indicate that network up time and network connectivity MTBF are the most 


important evaluation measures in extending CMA to Node 5. 


Influence of Functional Requirements on System Evaluation Measures 
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Evaluation Measures 
Figure 15. Influence of Functional Requirements on Evaluation Measures for 


xCMA. 

This chart synopsizes the relationship between the functional requirements and stated 
evaluation measures. As shown, network up time and network connectivity (MTBF) are 
the two most influential measurements. 


Following analysis of the Functional Hierarchy and QFD, the positive and 


negative evaluation measures were used to determine MOE for the xCMA system. These 


MOEs are: 
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Own Ship Position Info Sent Correctly 








MOE |: Probability that, upon command, the system will be fully 
functional within 4 hours 95% of the time. 


MOE 2: Probability that the system will connect to the CMA within 10 
minutes 95% of the time. This includes network connectivity, system 


identification and geolocation. 


MOE 3: Probability that the system will operate 1500 hours between 
failures 95% of the time. 


MOE 4: Probability that the system will sustain data throughput of 0.128 
Mbps 95% of the time. 


In summary, the value system design phase evaluated the system requirements 
identified in the Problem Definition Phase, identified the functional requirements, 
objectives and evaluation measures and translated these requirements into engineering 
terms and MOEs. These activities directly support the next phase of the process, Design 
and Analysis, which will facilitate the generation of alternatives and support decision 


making. 
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IV. DESIGN AND ANALYSIS 


A. DESIGN & ANALYSIS 


The next phase in the tailored systems engineering process is design and analysis. 
This phase consists of alternatives generation, including development of alternatives, 
feasibility screening, and modeling and simulation. Figure 16 illustrates the relationship 


of this phase to the overall process. 
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Figure 16. Design and Analysis Phase. 

This phase details the relationship between this phase and the remainder of the system 
engineering process. The focus in this phase is on alternatives generation and modeling 
and simulation. These activity results will assist in the decision making process. 


The purpose of these activities is to identify a set of key functions and evaluation 


measures to be used in the selection of the best candidate system configurations. These 
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candidate systems are then modeled and simulated. The results of the modeling and 
simulation provide guidance during the remainder of the system engineering process to 


ensure selection of the most appropriate system. 


B. ALTERNATIVES GENERATION 


The Alternatives Generation phase included the development of alternatives, 
feasibility screening and recommended alternatives. The results from the Functional 
Analysis, Functional Hierarchy, and QFD were utilized to focus the efforts in generating 
alternatives that meet the requirements. Alternatives generation identified the key system 
functions that the xCMA system requires to satisfy the effective need. These key 
functions were used in the development of the various xCMA system options. These 
options were then evaluated with the MOEs that were developed using the evaluation 
measures and QFD. This process is called feasibility screening. The screened system 
options were compiled into a list of recommended alternatives. These alternatives were 
then compiled into a Raw Data Matrix that highlights the key features of the xCMA 
system. The key features and representative functionality is modeled and simulated and 
the results used to assist in the evaluation and decision phase and in the selection of the 


most appropriate system. 


1. Alternatives Generation Assumptions 


° Due to the sensitive nature of military equipment, it would be 


restrictive to use military communications equipment 
® 802.16m is a viable communication means by implementation date 
° Web-based protocols are implemented 


® INMARSAT, KU band, Ultra-High Frequency (UHF) SATCOM, 
Transformational Communications Satellite (TSAT) are combined 


into SATCOM 


® Commercial SATCOM will use commercial router/modem and 


military SATCOM will use Tactical router/modem 
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e 802.16 implementation will use a commercial router/modem 


e Host to Communications (COMMS) interface is condensed into 
commercial and tactical router/modem that will be internal to the 


xCMA system 


° Software and services are developed and controlled by the CMA 
and will be loaded onto the host system prior to xCMA system 


delivery to the user 


° Consideration of software and services is the responsibility of the 


CMA JCTD and will not be evaluated in this effort 


° Display systems will be composed of conventional displays with 


an option for new technology 


° User interface is part of the host system 


Alternatives Generation Critical information used early in the 


decision making process 


e Differential GPS (D-GPS) was excluded due to its limited 


operating area (requirement calls for a global solution) 


e Software Defined Radios are flexible and can support a variety of 
networks (network agnostic) however they must be integrated with 
either SATCOM or Institute of Electrical & Electronics Engineers 
(IEEE) 802.16 


° Wireless 802.11 IEEE range is less than 10 miles, therefore does 


not meet the 30 nm requirement 


® INMARSAT bandwidth limitations are not feasible for handling 


streaming video 
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3. Development of Alternatives 


The development of alternatives was the result of brainstorming and brainwriting 
activities to ensure all inputs were considered. To satisfy the effective need, the three 
previously defined functions from the Functional Hierarchy and Value Systems Design, 
(Connect with CMA, Provide Collaboration and Manage Information) were used during 
the ensuing evaluations. A reiteration of the definitions of these functions is shown 
below. 

° 1.0 Connect with CMA — functionality involved with physically 

connecting the disconnected vessel with the Node 4 Functional Gateway, 


including locating and identifying the system. 


e 2.0 Provide Collaboration — bidirectional communication between the 
disconnected node, Node 5, and the Node 4 gateway. This includes 
sending, receiving and displaying all information including web services, 


UDAP, COI, etc. 


e 3.0 Manage Information — managing and handling of information local to 
the disconnected node. This includes data storage, and send, search and 


retrieval functionality. 


A product matrix was generated identifying system categories required to meet 
the functionality and system objectives defined in the functional analysis above. The 
categories and identified options are displayed in Table 9 and were the result of several 
discussion and discovery sessions. From this product matrix, an initial set of 72 xCMA 
system options were generated. A table of these options, numerically identified, is 


included in Appendix F. 
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Table 8. _ Initial xCMA System Categories and Options 


HOST to : 4 cn 
skid ia onan d ae eae 


INMARSAT(L-Band) a keyboard 
PDA Tacti ine 1 foe NIC (Network 
KU Band SATCOM aenea’ &xtema’ 1 DGPS - Internal touch screen Internal Man 
Router Interface Card) 
UHF SATCOM Commercial trackball 
Laptop Internal Router 
BEEOS Commercial ao ‘ nee 
DGPS - External plays 
Ship 








External Router voice : 
UHF-LOS IP Based easonnitIORS. External 
Desktop 2 


Tactical Internal i 
VHF-LOS Modem mic / speakers 








. : GPS - External headset 
Wireless PC Based Tactical External Remote 








(802.11/802.16) Modem J camera | 
camera 
Rack mounted SBCs Commercial Other Hardware 
Internal Modem . Helo 
New Technology Readable in 
GPS - Internal bricht light Removable 
ee card reader 
Software Definable Mobile Terminal Commercial 
Radios Equipment External Modem 


Evaluation Criteria 


Properly interfaces 
Bandwidth Scalable between Host & 
COMMS 


=+4/- i ‘ 
Accuracy Accuracy = 100% 7 48 hours of 
Smeters information 


Probability 
=90-95% 
Portable Access <10s 
Expandable Sort <10s 
Supportable Search < 10s 


Range >= 30 Nmi Plug & Play 


Maintainable 
Reliable 





In an attempt to reduce the options to a viable set of alternatives, an additional 
functional evaluation of the overall system was applied. A conducted priority ranking 
was applied to each functional category based on the risk and impact that each has on the 
overall system and its objectives. A scale of 1 to 10 was applied with 10 representing the 
greatest impact. A decision was made by the engineering team to group together the 
display and host system categories. The rationale behind this decision was based on the 
understanding that the host system type is indicative of the associated display type. For 
example, a laptop solution for the host system determines a Liquid Crystal Display 
(LCD) for the display type. Figure 17 shows the final functional categories and the 


evolution from the original list with ranking/weighting values to the final top 5. 
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Functional Category Ranking unctional Category 


ommunications : ommunications 
dentify : dentify 

ost to Comms Interface ost to Comms Interface 

LI LI 

isplay ost System (incl Display) 
ost System 
eployability 
ser Interface 
torage 





Figure 17. Functional Categories. 

During alternatives generation, it was necessary to reduce the options to a realistic 
number. To accomplish these rankings were applied to the functional categories to 
determine which functional areas needed to be the focus. This diagram shows the 
evolution of these categories and their relative ranking factors. 


It was determined that although Manage Information is an important part of the 
system, the functionality is easily satisfied by a variety of typical software and storage 
systems commercially available and is not a limiting factor of the xCMA system. For 
this reason, it was removed as a focal point for alternatives generation. 

With Manage Information removed as a key focus, the primary functions for 
evaluation and consideration are reduced to Connect with CMA and Provide 
Collaboration. These functions represent the xCMA system’s ability to physically 
connect to a CMA gateway, identify the vessel and the vessel’s location, and to provide 
bidirectional communications and display capability for all data and services. 

The product matrix previously generated was modified to represent the decisions 
identified above. Changes were also made regarding the COMMS category. First, due to 
the requirement to connect to a Node 4 gateway within a 30 nm range, the Line of Sight 
(LOS) options were removed. Second, the SATCOM category was identified as 
Commercial only due to the unclassified nature of communications and the need to 
connect with other nations and entities for humanitarian efforts. Research further showed 
that INMARSAT does not handle the streaming video requirements. In addition, new 
technology was determined not to meet a 2010 implementation schedule and therefore 
would not be evaluated due to the lack of system specifications available for evaluation. 


Upon defining MTE, it was determined that MTE was effectively another form of a SBC. 
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These two categories were combined under the SBC category. The resulting matrix is 
displayed in Table 9 and includes the following categories of focus; Communications, 


Host System, Router/Modem, Position Location Information, Display and Identify. The 


definition of each category is defined below. 


Table 9. 


SATCOM- 
Commercial 


Wireless (802.16 
or equiv) 


Host System 





SATCOM — 
Military / 
Government 


New 
Technology 





Software 
Definable Radios 


Router/Modem 


Commercial 


Tactical 


Revised xCMA System Categories and Options 


Evaluation Criteria 


Display 


New 
Technology 





Identify 


NIC MAC 
Address 


Other 
Hardware / 
New 
Technology 




















Properly 
: interfaces ae Accuracy = 
Bandwidth Scalable beiwecn Hoste ol +/- 100% 
COMMS Smeters 
Range >=30nm | Plug & Play 
Portable 
Expandable 
Supportable 
Maintainable 
Reliable 




















e The COMMS components maintain connectivity to any CMA gateway within 30 
nm from Node 5. It is a means that allows the xCMA system to communicate 


with a CMA gateway. The communications link can be in any format, such as 
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SATCOM or a wireless point to point link. The 30 nm requirement excludes 


consideration of Line-of-Sight (LOS) communications systems. 


The Host System is comprised of components that function as the computing and 
storage components for the xCMA system. The Host System also includes user 
interfaces that allow the xCMA user to input data, retrieve data, and communicate 
with the system. It is understood that current COTS personal computer systems 
are capable of handling throughput sufficiently greater than the required 0.128 
Mbps of incoming data. For this reason, the detailed specific internal components 


of the Host System are not a constraint and therefore not evaluated. 


The Host to COMMS interface provides the functionality to relay transmitted 


information between the communications components and the Host system. 


PLI is used to accurately provide own ship position using GPS satellites. This 
information is reported to the CMA and is available to the ship personnel. This 
PLI can be generated automatically based on the GPS input or manually entered 


by the user as part of a query filter that is sent to Node 4 for UDAP data. 


The Display function component is used to display CMA data. This allows the 


presentation of information and data to the operator. 


The Identify function component is a requirement to provide a unique identifier 
for each xCMA system. This allows accurate logistics, provides some inherent 
security functionality, and is responsible for providing self-identification 
automatically and independently from the Node 5 user. In this study, the NIC is 
used to provide a unique 48-bit serial number called a MAC address. Another 


option is the IP. 
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e The Router/Modem provides the functionality to relay transmitted information 


and connect to the CMA network. It provides the network interface going from 


Node 4 and Node 5 xCMA system. 



























































Table 10. | Updated List of Alternatives 
COMMS Host System Router/Modem PLI Display Identify 

SATCOM — Commercial Laptop Commercial GPS LCD MAC/IP 

M — Commercial New Technology Commercial GPS | New Technology | Other HW, new tech 

SATCOM -— Commercial SBC Commercial GPS LCD MAC/IP 

SATCOM — Commercial Mobile Terminal Commercial GPS LCD Other HW, New Tech 
Equipment 

SATCOM - ‘ 

Military/Goverament Laptop Tactical GPS LCD MAC/IP 

SATCOM - : 

Military/Government New Technology Tactical GPS | New Technology | Other HW, new tech 

oo SBC Tactical GPS LCD MACIIP 

Military/Government 

eee: Mobile minal Tactical GPS LCD Other HW, New Tech 

Military/Government Equipment 

Wireless 802.16 Laptop Commercial GPS LCD MAC/IP 

Wireless 802.16 New Technology Commercial GPS | New Technology | Other HW, new tech 

Wireless 802.16 SBC Commercial GPS LCD MAC/IP 

Wireless 802.16 oe ee Commercial GPS LCD Other HW, New Tech 
Equipment 

Software Defined Radio Laptop Commercial GPS LCD MAC/IP 

Software Defined Radio | New Technology Commercial GPS | New Technology | Other HW, new tech 

Software Defined Radio SBC Commercial GPS LCD MAC/IP 

Software Defined Radio Mobile oe Commercial GPS LCD Other HW, New Tech 
Equipment — 




















Additional analysis was conducted to further refine the alternatives. The analysis 


included research on available technologies, earlier assumptions, and evaluation of 


requirements. Since the xCMA system is deployed to foreign allies and restrictions exist 


in the use of tactical equipment, all tactical equipment was eliminated from the list of 


alternatives. Software Defined Radios (SDRs) do not have their own communications 


means. To use SDRs either a wireless protocol or satellite communications system will 


need to be incorporated. Given this restriction SDRs are eliminated from the list of 


alternatives. The portability requirement eliminates the desktop and Cathode Ray Tubes 


(CRT) due to bulk and fragility. The final list of alternatives is shown in Table 11. 
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Table 11. | xCMA System Alternatives 
: Router : ; 
Alternatives COMMS Host System /Modem PLI | Display | Identify 
pees perce Laptop Commercial | GPS | LCD |MAC/IP 
Laptop Commercial 
Integrated SBC 
ee — oe Mobile Terminal | Commercial | GPS} LCD |MAC/IP 
Equipment(MTE) 
oe Wancles- Wireless 802.16 Laptop Commercial | GPS | LCD |MAC/IP 
Laptop 
4. Wireless-SBC | Wireless 802.16 ie Commercial |GPS] LCD | MAC/IP 























A detailed account of alternatives generation is included in Appendix F and a 


design description of each of the alternatives follows. 


Alternative 1: SATCOM-Laptop Alternative — A SATCOM capability is used 
as the communications means for connecting to the CMA network. The information from 
the host system laptop is routed through the modem and then transmitted by the satellite 
transmitter to the Node 4 satellite receiver. The information from Node 4 is transmitted 
by a satellite transmitter and received by the system satellite recetver and demodulated 
for processing by the host system laptop. The NIC provides the system with a unique 
hardware MAC address for the system identification. A COTS GPS receiver will be used 
to provide system PLI. 

Alternative 2; SATCOM- SBC Alternative — A SATCOM capability is used as 
the communications means for connecting to the CMA network. The information from 
the host system MTE consisting of an SBC, modem/router, power supply, display, and 
input devices packaged in a ruggedized, transportable container is routed through the 
demodulator modem and then transmitted by the satellite transmitter to the Node 4 
satellite receiver. The information from Node 4 is transmitted by a satellite transmitter 
and received by the system satellite receiver and demodulated for processing by the host 
system MTE. The NIC provides the system with a unique hardware MAC address for 
system identification. A COTS GPS receiver is used to provide system PLI. 
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Alternative 3: Wireless (802.16m)-Laptop Alternative — A wireless broadband 
communications capability is used as the communications means for connecting to the 
CMA network. The information from the host system laptop is transmitted by the RF 
transmitter to the Node 4 RF receiver. The information from Node 4 is then transmitted 
by the RF transmitter and received by the system RF receiver for processing by the host 
system laptop. The NIC provides the system with a unique hardware MAC address for 
system identification. A COTS GPS receiver is used to provide system PLI. 

Alternative 4: Wireless (802.16m)-SBC Alternative — A wireless broadband 
communications capability is used as the communications means for connecting to the 
CMA network. The information from the host system MTE consisting of an SBC, 
modem/router, power supply, display, and input devices packaged in a ruggedized, 
transportable container will is transmitted by the RF transmitter to the Node 4 RF 
receiver. The information from Node 4 is transmitted by the RF transmitter and received 
by the system RF receiver and demodulated for processing by the host system MTE. The 
NIC provides the system with a unique hardware MAC address for system identification. 


A COTS GPS receiver is used to provide system PLI. 


C. FEASIBILITY SCREENING 

Feasibility Screening facilitates solution selections for the four system 
alternatives. The purpose of this activity is to validate, at a high level, the realistic 
applicability of the defined alternative as a solution for the defined problem. This is 
accomplished by evaluating the alternatives using the previously developed MOEs and 
Evaluation Criteria. Table 12 details the results of the feasibility screening of the four 


identified system alternatives and a non-materiel solution. 
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Table 12. 


xCMA System Feasibility Screening 


















































Feasibility Criteria 
: Communications | Display Data Identification 
Design Name 
>30 nm Range Network & Info Accuracy SUMMARY 
Interface Correctly 100% 
SATCOM. G cc G G 
Laptop 
SATCOM- G G Ge @ 
SBC 
Wireless- re G G G 
Laptop 
Wireless-SBC G G G e 
Non-Materiel NG NG NG NG 
G - Go 
NG - NoGo 
Green - Meets requirements 
Yellow - Does not fully meet requirements 
Red - Does not meet requirements 








A Non-Materiel solution is included during feasibility screening to ensure that all 
possible solutions are considered. The non-materiel solution uses existing networks and 
infrastructure and focuses on modification of mission responsibilities, operational 
concepts and technologies. Existing systems do not meet the system requirements to 
provide adequate CMA connectivity to the disconnected vessel or user. Limited 
connectivity could be provided on an adhoc basis using existing Ultra High Frequency 
(UHF)/Very High Frequency (VHF) radio telephones and possibly messenger services 
(small boat and helicopter delivery of maps, orders). This does not provide a sustained 
capability for Node 5 to effectively and efficiently communicate with the humanitarian 
operation vessels using streaming video, text, pictures, e-mail, and chat. This solution 
does not provide the required Node 5 connectivity. 

The SATCOM alternatives, both laptop and SBC, satisfy all of the identified 
feasibility criteria. The Wireless (802.16m) alternatives, both for laptop and SBC, satisfy 


the feasibility criteria with an associated risk due to immaturity of the standard. This risk 


Tt 


is associated with the range limitations of the current 802.16e standard. 802.16m has 
better mobility and increased range as well as higher throughput rates. However, this 
version (IEEE Specification C802.16m — 07/003) is still in work and not yet formally 
released. Therefore, the feasibility criteria related to range and 100% identification are 


identified as risk areas. 


D. MODELING & ANALYSIS 


In system engineering, a model is developed to evaluate the measures of 
effectiveness of a system being designed. The created model is an incomplete 
representation of reality, an abstraction of the system. Furthermore, the created models in 
this study are mathematical abstracts of the system. A random number generator is used 
to model the propensity of the system characteristics. The modeling and analysis phase 


includes the raw data matrix, reliability modeling, and the throughput modeling. 


1. Raw Data Matrix 


The Raw Data Matrix highlights several features of the xCMA system. The 
specific information is supported by the modeling contained in the following sections. 
The throughput (=> Mbps) measurement is a simple function of the peak bandwidth 
capabilities based on COTS hardware components. The data is generated using hardware 
performance values from multiple SATCOM terminal systems, 802.16 wireless systems, 
personal laptop computers, SBCs, router/modems, LCD monitors, and NICs. 

Some critical assumptions about the system include the following. First, the 
processor speed and throughput are not an issue of concern for this system as a generic 
COTS personal computer would adequately handle processing requirements. Second, 
Network Time Allocations are not under the control of the xCMA system and are not 


used in the throughput calculations. 


73 


Table 13. | Raw Data Matrix for the xCMA system 
Alternatives 


SATCOM- | SATCOM- Wireless- Wireless- 
Laptop SBC Laptop SBC 

System Functional 

<4 hours Y Y Y Y 


Connect to CMA < 10 
minutes 





Evaluation 
Measure 














Y Y Y Y 





The system will be up 
and operational at least 
1500 hours between 
failures. MTBF (hours) 91.52% 94.43% 94.76% 
= 1500 





The probability that the 
system will be able to 
meet the required data 
throughput 95 % of the 
time 99.57% 99.57% 
Throughput > 0.128 
Mbps 














Note to Table 13: Estimated data points are in PURPLE; Hard Data points are in Black. 


2. Reliability Modeling 


A mathematical model was used to evaluate system reliability. For reliability to 
be measured, the system must be under a specific set of maintenance and operational 
conditions. Reliability is treated as a probability and therefore has a distribution. 

From the Raw Data Matrix, the MTBF was selected to measure the reliability of 
the system. The values of the MTBF for the different system components were obtained 
by averaging the published MTBF values obtained from similar products. 

The reliability model of the system consists of five component categories as 
detailed in Table 14. The reliability for each component as a function of mission time 
(R(t)) can be then calculated by using the following equation: 


sb 


R(t) =e MTBF 





Eq. (1) 
The total reliability of each alternative was calculated using the series system 


formula as follows: 
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R sysiem= Ri*.R2*R3* RX Rs Eq. (2) 


The mission time of 14 days (336 hours) is used in the calculations and the value 


for each component’s reliability is shown in Table 14. 


Table 14. | xCMA System Component Reliability Calculations 





























Components Rone 
Communications: SATCOM-Commercial 96.36% 
Communications: Wireless 802.16 99.76% 
Host System: Laptop 96.69% 
Host System: Single Board Computer (MTE) 99.77% 
Router/Modem: Commercial 99.95% 
Display: LCD 98.52% 
Identify: MAC Address 99.76% 








To determine the simulated system alternative reliabilities, the components of 
each alternative were grouped together. Each alternative was simulated using Microsoft 
Excel with a random function. Each model was simulated with 300 replications to reach 
result stability and ensure a 95% confidence interval. The results are summarized in 


Table 15. The detailed simulated results are shown in Appendix G. 


Table 15. | Simulated xCMA System Reliability Results for the Alternatives 























Alternatives Reliability Simulations Results 
SATCOM-Laptop 91.52% 
SATCOM-SBC 94.43% 
Wireless-Laptop 94.76% 
Wireless-SBC 97.77% 





The simulated system reliability values in Table 15 above were then used to 
calculate the system MTBF values. The system MTBF results are shown in Table 16 and 
are used in conjunction with the MTBF Multi-Attribute Utility Theory (MAUT) to 


determine a weighted score for each of the alternatives. 


qo 


Table 16. _ Simulated xCMA System MTBF Results for the Alternatives 























Alternatives Simulated MTBF Results (hrs) 
SATCOM-Laptop 3,794 
SATCOM-SBC 5,863 
Wireless-Laptop 6,246 
Wireless-SBC 14,880 





3. Throughput Modeling 


Throughput is one evaluation measure in the Raw Data Matrix. For the xCMA 
system modeling and simulation, throughput is referred to transmission performance of 
data and is measured by transmitted or received data during a certain period of time. The 
throughput of a connection depends on the Central Processor Unit (CPU), memory, and 
any other processing components that are linked together. Throughput is a measure in 
megabits per second (Mbps). The requirement for the xCMA system has been defined by 
the stakeholders as greater than or equal to 0.128 Mbps. 

To measure and analyze the throughput of the system, a model similar to that of 
reliability was used. The system components are connected in series. 

The throughput model data is based on research of similar systems in the 
commercial sector. Each alternative’s components are assigned with average values of 
throughput from manufacturer’s published values. Since the model was created with 
components connected in series, the overall system throughput could be determined by 
the subcomponent that has the lowest throughput for each alternative. This can be 


represented as follows: 


T ues 7 Min( Tels TT, T2 Eq. (3) 


Based on the system throughput equation above, each of the components has a 
calculated throughput value as shown in Table 17. The detailed throughput calculations 


and results are shown Appendix G. 
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Table 17. _ xCMA System Component Throughput Calculations 


























Component el 
Communications: SATCOM-Commercial 0.235 
Communications: Wireless 802.16 100 
Host System: Laptop 322 
Host System: SBC (MTE) 2,008 
Router/Modem: Commercial 3,329 
Display: LCD 1,064.960 
Identify: MAC Address 235.000 


The model uses a random exponential arrival and service distribution. The 
evaluation measures from the Raw Data Matrix of the xCMA system alternatives are 
simulated and captured for comparison. Each component’s throughput is simulated with 
30 replications (500 runs each). The throughput results are shown in Table 18 and 
detailed results are shown in Appendix G. The results indicate that all alternatives meet 
the minimum required throughput of 0.128 Mbps. Also, the simulated results support the 


evaluation measures in the Raw Data Matrix. 


Table 18. | Throughput Simulations Results for xCMA System Alternatives. 

















Alternative Required The probability that 95 % of the time 
Throughput Met? Throughput > 0.128 Mbps 
SATCOM-Laptop Yes 99.57% 
SATCOM-SBC Yes 99.57% 
Wireless-Laptop Yes 99.97% 
Wireless-SBC Yes 99.97% 
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V. DECISION MAKING AND RECOMMENDATIONS 


A. DECISION MAKING 


The final phase in the tailored systems engineering process is decision making. 


This phase consists of Analysis of Alternatives and Recommendation as shown in Figure 
19. 
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Figure 19 Decision Making Phase. This figure highlights the Decision Making activities 
completed in the tailored system engineering process. 


The purpose of these activities is to analyze the viable alternatives from the 
Design and Analysis phase and to numerically score the alternatives so that a final 


recommendation can be given to the stakeholders. The analysis of alternatives includes 
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the development of MAUT scores, a decision matrix, and sensitivity analysis. The results 
from these work products were then used in the final recommendation. 


1. Decision Matrix 


The Decision Matrix is the result of the application of global weights and MAUT 
scores on the four xCMA system alternatives. MAUT provides a systematic, objective, 
and quantitative way of identifying and analyzing multiple variables and objectives to 
form a common basis for arriving at a decision. The MAUT utilities are captured from 
the stakeholders with the level of importance of each utility reflecting the preference of 


the stakeholders. 


MTBF was one of the evaluation measures examined and applied with MAUT. 
Research of similar current systems provided MTBF data for each system component. 
This data was statistically analyzed and the mean value was used in the simulation. Table 
19 provides the values from the simulation. This data was used to extract the 


corresponding value from the MAUT curve as displayed in Figure 20. 


Table 19. _xCMA System Alternatives Mean Time Between Failure Comparison 














Ranking Alternative MTBF (Hrs) Symbol 
1 Wireless - SBC 14,880 Oo 
2 Wireless - Laptop 6,246 © 
3 SATCOM-SBC 5,863 cA 
4 SATCOM-Laptop 3,794 A 

















Table 19 summarizes the outcome of the modeling and simulation results for each 
alternative. These results were based on existing systems reliability data. The results are 
ranked according to their resulting mean time between failure data. A MTBF of equal or 
greater than 1500 hours was determined to be the minimum requirement based on 
standard MIL-PRF-28800F. 
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Figure 20. MTBF MAUT Utility for xCMA System Alternatives. The MAUT tool 
details the relative comparison of the four system options based on mean time between 
failure. 

Throughput was the second evaluation measure examined. Research of similar 
current systems provided throughput data for each system component as in Table 20. 
This data was statistically analyzed and the mean value was used in the simulation. The 
components for each alternative were reviewed. The component with the smallest 
throughput was used to extract a MAUT value from the utility curve as shown in Figure 
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Table 20. |. xCMA System Alternatives Throughput Comparison 














Ranking Alternative ane Symbol 
Wireless — SBC and 
Lene Wireless - Laptop aoe? =? 
SATCOM-Laptop and 
3 and 4 SATCOM.SBC 0.235 A 

















Table 20 summarizes the outcome of the modeling and simulation results for each 
alternative. These results were based on throughput data from existing systems. The 
results are ranked according to their resulting throughput. The minimum throughput 
acceptable was determined to be equal to or greater than 0.128 Mbps based on 
stakeholder feedback. 
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Throughput for xCMA System Alternatives 
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Figure 21. MAUT translation of throughput for the xCMA system alternatives. The 
MAUT values for throughput are mapped into a 0 to 100 point scale. 


Technology Readiness Level (TRL) was the third evaluation measure examined. 
Research was performed on each of the alternatives and based on the results, the TRL 
levels were assigned as in Table 21. The MAUT values were extracted from utility curve 


in Figure 21. 


Table 21. | xCMA System Alternatives TRL Comparison 























Ranking Alternatives TRL Symbol 
SATCOM-Laptop and 
rete SATCOM-SBC : = = 
Wireless — SBC and 
oe Wireless — Laptop : @ ¢ 








Table 21 summarizes the results of the TRLs for each alternative. These results were 
based on research. To mitigate risk a decision was made to use a system with TRL equal 
or greater than 6. 
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xCMA System Alternatives 





: : SATCOM - Laptop 
Wireless — SBC : 





: Wireless — Laptop 














Figure 22. MAUT translation of TRL for the xCMA system alternatives. The MAUT 


values for TRL are mapped from 0 to 9 into a 0 to 100 point scale. 


The Decision Matrix captures and uses weighting factors from the stakeholders to 
bring out the level of importance of each evaluation measure. The weights of all 


evaluation measures are normalized to a total value of 100%. 


Once the MAUT utilities and global weights are determined, the results from the 
Raw Data Matrix are translated into the Decision Matrix. The score of each evaluation 
measure of the xCMA system is extracted from the corresponding MAUT utility curve, 
as in Figure 20 to Figure 22, to capture the objective score for each of the four xCMA 
system alternatives. The MAUT scores are then weighted using the corresponding global 
weight to provide the final score represented in the Decision Matrix. The scores of each 


xCMA system alternative are then summed to determine the final total score as shown in 


Table 22. 
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Table 22. Decision Matrix for the xCMA system 


Raw Data Matrix Decision Matrix 
Alternatives Alternatives 
SATCOM-Laptop SATCOM-SBC Wireless-Laptop Wireless-SBC 


Evaluation 5 : Evaluation | Global 
M Wireless- | Wireless- Mensur 
easures een SBC sures 





¥ ¥ 


94.76% | 97.77% 


99.97% | 99.97% 











98 : 98 E 80 24 80 


| Total Value Score | | 95.65 | | 96.90 | 93.50 | 94.00 | 








The Total Value Scores resulted in the SATCOM-SBC system alternative having 
the highest value at 96.90 out of 100 possible points. The second highest value is 95.65 
for the SATCOM-Laptop system alternative. The third alternative, Wireless-SBC, rates 
lower at 94.00. The Wireless-Laptop system alternative has the lowest score at 93.50. 
The results from the alternative scoring indicate the SATCOM-SBC option is the 
recommended solution, however, the results also indicate that all system alternatives 


exceed the evaluation criteria. 


2. Sensitivity Analysis 
During the sensitivity analysis process, the evaluation criteria are defined and 
assessed with respect to each of the alternatives. The evaluation criterion is detailed in 


the sections below and the value charts are based on MAUT. 


System Functional (< 4 hours): This evaluation measure is weighted by 
assigning a numerical value between 0 and 100 to the estimated xCMA system set 
up time. All four alternatives scored satisfactorily, and met the operational 


requirements. 


Connect to CMA (< 10 minutes): This evaluation measure is weighted 


by assigning a numerical value between 0 and 100 to the estimated time from 
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xCMA system turn-on to actual connection to the CMA. All four alternatives 


scored satisfactorily, and met the operational requirements. 


Required Throughput (=95%): This evaluation measure is weighted by 
assigning a numerical value between 0 and 100 to the required throughput 
percentage; the higher the percentage of throughput above 95%, the higher the 
score. All four alternatives scored satisfactorily, and met the operational 


requirements. The alternatives including the Wireless option scored 100. 


MTBF (hours): This evaluation measure is weighted by assigning a 
numerical value between 0 and 100 to the MTBF; the higher the MTBF, the 
higher the score. All four alternatives scored satisfactorily, and met the 


operational requirements. 


Technology Readiness Level (TRL) ( > 6): This evaluation measure is 
weighted by assigning a numerical value between 0 and 100 based on the TRL 
values of 0 to 9. The SATCOM based systems both scored 98 and the wireless 


systems scored an 80. 


B. RECOMMENDATION 


Through the culmination of the efforts of applying the tailored systems 
engineering process and using the results of the tools and activities leading to the 
generation of the decision matrix and the sensitivity analysis the resulting 
recommendation indicates all four options are viable systems and are capable of 
providing a solution to the problem. The Satellite Communication (SATCOM) with a 
Single Board Computer (SBC) alternative, however, is the higher ranked configuration 
for extending CMA to a disconnected node in support of humanitarian efforts. In this 
approach a SATCOM capability is used as the communications means for connecting to 
the CMA network. The information from the host system consisting of an SBC, 
modem/router, power supply, display, and input devices packaged in a ruggedized, 


transportable container is routed through the modulator demodulator (modem) and then 
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transmitted by the satellite transmitter to the Node 4 satellite recetver (Node 4 details are 
to follow). The information from Node 4 is transmitted by a satellite transmitter and 
received by the system satellite receiver and demodulated for processing by the host 
system. The Network Interface Card (NIC) provides the system with a unique hardware 
Media Access Control (MAC) address for system identification. A Commercial-Off- 
The-Shelf (COTS) Global Positioning System (GPS) receiver is used to provide system 


Position Location Information (PLI). 


C. FUTURE ACTIVITIES 


The systems engineering process focuses on technology research, analysis, and 
solutions. Cost with regards to technology tradeoffs was not performed on the generated 
alternatives or considered in the decision making. Because all the evaluated alternatives 


are considered to be viable options, future cost analysis should be conducted. 


The current 802.16e range capability lacks the 30 nm requirement by 4.5 miles. 
One capability proposed in the 802.16m standard states improved range, which has yet to 
be defined. It is an assumption that the proposed increase in range will meet the 30 nm 
requirement. The standard is scheduled to be completed by 2009. The 802.16m 
technology is a viable future option, once the TRL matures and systems become readily 


available. 


The SBC requires further integration and this was not addressed in the evaluation 
of the system. Integration effort in this alternative could lead to additional technology 
requirements and costs. These considerations are disadvantages for this particular 


alternative. Therefore, the laptop solution may be a more viable current implementation. 
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Scope: 


APPENDIX A. STATEMENT OF WORK 


Comprehensive Maritime Awareness for Non-CMA Connected Nodes 


This task investigates the extension of Comprehensive Maritime Awareness to non 
connected nodes to facilitate continued information sharing. The specific focus will be 
on the architecture required to ensure that previously non-CMA connected nodes and end 
users are active participants in CMA. The following will be the primary scenarios used 
for validating the candidate architecture. 


Non-CMA Connected Vessel - Connectivity of planned, non operative CMA node 


* Coast Guard small boat that doesn't have capability to do (fusion, MDA 
CONOPS objectives) 


* Red Cross type ship; Navy Hospital Ship 


* Commercial ship 


Assumptions: 
The following assumptions are made regarding this effort. 


CMA systems exists and are fully operational (Nodes 1 through Node 4) 

Node 4 will use existing fusion and operational capabilities to enable 
disadvantage node connection to the CMA. It will be responsible for its own 
information and data flow to the CMA as well as the info from the previously 
non-connected Node 5. 

Connections will involve unclassified data only 

Regional gateway will be MHQ with MOC (Node 3) 

Connectivity between Node 4 and Node 5 will be provided by a “black box” 
connectivity system. 


Guidance for Architecture: 


Use CMA OV-1 and OPNAV N6 OV-1 (from MDA N6 Brief) as a high-level 
view and assumption to their architecture development. 

Also use MHQ with MOC OV-1 

Size, power and weight constraints similar to small vessels and assumes max 
distance to node 4 of 30 nm 


CDD Guidance: 
Assume CMA capabilities are there. Develop CDD to support CMA Node 4 and Node 5, 
as defined above, under the Fleet CMA CONOPS/Architecture. 


The work product will be an appendix and will be delivered in lieu of Chapters 4 
& 5 of the Project Report 
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— The ICD requirement for the MDA CDD was fulfilled with the following 
documents: 

— National CONOPS to Achieve Maritime Domain Awareness 

— Fleet CONOPS for Maritime Domain Awareness 

— Fleet MHQ/MOC CONOPS 

— GMII CONOPS 

— CMA Implementing Directive (Joint Requirements Oversight Council Approved) 

— CMA CONOPS 


CDD Guidance: 

Definitions: 

The following definitions will be used for Node 4 and Node 5 for this effort. 

Node 5: Vessel with sensor capabilities (none to extensive) and having either limited or 
no CMA connectivity 


Node 5: A Node 5 participant is a user or vessel with sensor capabilities varying from 
none to extensive, that does not have a direct connection to the existing CMA network. 
This node will be limited to sending request for area information, providing aperiodic 
manual sensor or visual information and receiving updates from Node 4. The following 
characteristics apply: 

— No data fusion capability 

— Limited sensor data available 

— Provides input into CMA network via node 4 connection 

— Receives guidance from CMA network regarding mission specific info 


Node 4: The Node 4 asset will be the gateway between the Node 5 and the CMA 
network. It will be provide connectivity between Node 5 and all other CMA nodes. It 
will be capable of : 
— Collecting CMA data, including data from Node 5 and providing it to the CMA 
network 
— Fusing maritime data/info, CMA and Node 5 using existing CMA fusion 
capabilities 
— Assessing threats; alerts 
— Sharing threats & picture; including providing the UDAP for Node 5 


Technical Requirements: 
Statement of Work: 

— Characterization of the Problem Space: the identification of current system 
“as is”) and the deficiencies as well as constraints inherent in the operational 
environment in order to characterize, understand and bound the problem space. 
The project team will identify and translate CMA functions from the Fleet MDA 
CONOPS, National MDA CONOPS, and the CMA CONOPS into system 
engineering structures (“to be” concepts, data models, and architecture functions, 
requirements, solutions) necessary to develop the node 4 and node 5 connectivity 
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concept. The project team will evaluate the functions, requirements and 
architectures in support of the integration of CMA requirements. 


Functional Representation And Decomposition: the representation of system 
concepts through functional description and decomposition as well as system 
architecting (DoDAF models) and simulation. Develop representations, models, 
and methods to express automated resource collaboration concepts and 
information sharing solutions in the context of the CMA architecture and 
domains. The project team will develop a system model and architecture to 
evaluate the performance of the proposed architecture. 


Analysis of Key Capabilities: the identification and evaluation of technologies 
and research areas key to the integration of Nodes 4 and 5 into the CMA concept. 


Deliverables: 
a. Project Report — Will include chapters 1-5. 
b. In Progress Review — Status review provided end of Quarter 2. 
c. Final Presentation 


THIS PAGE INTENTIONALLY LEFT BLANK 
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APPENDIX B. INPUT/OUTPUT ANALYSIS 


The Input/Output analysis was performed as a first step in defining the needs and 
constraints for the xCMA system. The complete input/output analysis is shown in Figure 
B-1. The purpose of this diagram is to indicate the flow of information between the 
inputs and the transformation of those inputs into outputs for the xCMA system. The 
Input/Output analysis concentrates on defining the requirements and not the functions of 
the system or functional requirements. The required inputs were broken down into 
controllable and uncontrollable inputs and the related outputs were intended and 
unintended, or by-products. Intended inputs are those inputs that are determinable or 
controlled and the unintended inputs cannot be controlled. Desired outputs are shown as 
intended outputs and the by-products are identified as undesired outputs. The desired 
outputs are the main purpose for the xCMA system and ultimately define or meet the 
needed requirements. During the input/output analysis, constraints were identified while 


still meeting the requirements of the effective need statement. 


Controllable 


Fused CMA Information 
UDAP 

Warnings/Alerts 
Position Information 
System Authentication 
Bandwidth 

Local Awareness 


Extend CIVA to 
INPUTS Disconnected 

















Uncontrollable 


Incorrect Information 

Weather 

Environment 
Jamming/Meaconing/Malicioius 
attacks 

e Security Violation (unintended 
classified info) 


Intended 





Consolidated CMA Information 
UDAP 

Warnings/Alerts for Area of Interest 
Position Information 

Validated Authentication 

Scalable bandwidth on Demand 


By-Product 


Incorrect Information 
Too much Information 
Unusable Information 
Loss of Information 


Security Violation (unintended classified 
info) 


Figure B-1. xCMA Input-Output Analysis. The Input/Output analysis was performed as a first 
step in defining the needs and constraints for the xCMA system. The purpose of this diagram is 
to indicate the flow of information between the inputs and the transformation of those inputs into 


outputs for the xCMA system. 


APPENDIX C. FUNCTIONAL FLOW BLOCK DIAGRAM (FFBD) 


In order to perform a basic functional decomposition of the system a FFBD was 
constructed. This FFBD decomposed each level, or basic function to better understand 
how the information flows through the proposed system. Inputs to the system enter from 
the left and exit to the right as outputs. The functional flow block diagram is shown in 
Figures C-1 through Figure C-7. Figure C-1 shows the main functions of the proposed 
xCMA system. Figure C-2 shows the flow of information for the Connect with CMA 
function. Figure C-3 shows the flow of information for the Provide Collaboration 
function and Figure C-7 shows the flow of information for the Manage Information 
function. The Provide Collaboration function has several subsets, or subnodes, which are 
identified as Receive, Send, and Display Information and are shown in Figure C-4, Figure 


C-5 and Figure C-6, respectively. 


“And” connectors are used to show parallel functions that are accomplished and 
“Or” connectors are used where the flow of information can proceed any one function. 
The flow of information is always shown to go from left to right. Decomposition of 


functions is shown as references. 


1.0 2.0 3.0 
Connect with >» Provide » Manage 
CMA Collaboration Information 


Figure C-1. xCMA Main Functions Functional Flow Block Diagram. This figure depicts 
the top level functions of the xCMA system in a functional flow block diagram format 


1.2 
> . 
1.0 Ref 1.1 Identify 
Connect with » Achieve > AND > 
CMA Network 13 
Connection 
Locate 


Figure C-2. xCMA Connect with CMA Functional Flow Block Diagram. This figure 
depicts the Connect with CMA functions of the xCMA system in a functional flow block 
diagram format 


24 
> Receive 
2.0 Ref Information 2.3 
Provide » AND > Display 
Collaboration 2.2 Information 
> Send 
Information 


Figure C-3. xCMA Provide Collaboration Flow. This figure depicts the Provide 
Collaboration Flow in the xCMA system in a functional flow block diagram format. 
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Warnings & 
2.1 Ref Alerts 


Receive » AND > 
Information 2.1.4 


» Receive 
Retrieved 
Information 


2.1.5 


> Receive COI 
Information 


2.1.6 


» Receive Web 
Service 
Information 


Figure C-4. xCMA Subnode Receive Information Functional Flow Block Diagram. This 
figure depicts the Receive Information portion of the xCMA system in a functional flow 
block diagram format. 
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Send Own 
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Send 
Subscription 
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2.2.3 


Send Local 
Awareness 


2.2.4 


Send 
Warnings & 
Alerts 


2.2.5 


Send Web 
Services 


Figure C-5. xCMA Subnode Send Information Flow. This figure depicts the Send 
Information portion of the xCMA system in a functional flow block diagram format. 
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2.3.1 


» Display 
Archived 
Information 


2.3.2 


>» Display 
UDAP 


2.3 Ref 2.3.3 


Display » AND > Display > 
Information Web Services 


2.3.4 


» Display 
Warnings & 
Alerts 


2.3.5 
» Display COl 
Information 


Figure C-6. xCMA Subnode Display Information Functional Flow Block Diagram. This 
figure depicts the Display Information portion of the xCMA system in a functional flow 
block diagram format. 
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3.1 
> Store 
Information 
3.0 Ref 3.2 
Manage r AND» Purge Dated > 
Information Information 
3.3 


» Access 
Information 


Figure C-7. xCMA Manage Information Functional Flow Block Diagram. This figure 
depicts the Manage Information portion of the xCMA system in a functional flow block 
diagram format. 


APPENDIX D. IDEFO 


A functional model of the xCMA system was constructed using IDEFO. The 
IDEFO model structurally reflects the system functions and shows the flow of information 
connecting these functions. The basic functions used in the IDEFO model were 
previously identified in the FFBD. The IDEFO model identifies input data and the 
processing as well as analysis that takes place as part of the model. Identified are also 
inputs that are required from the User at the disconnected vessel, information that is sent 
via the xCMA system to the gateway node, and information that is received via the 
gateway node. This aids in determining the requirements for processing and receiving of 
the various kinds of data as well as operator interfaces that are incorporated into the 
design. The various kinds of information that transfer between the xCMA system and the 
gateway node are then used to calculate requirements for bandwidth and for optimization 
of the overall system. The model further aids in identifying requirements that satisfy the 
effective need and validation of these requirements through stakeholder inputs. The 


complete IDEFO model is shown on Pages D3 through D10. 
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Figure D-1. xCMA Context Diagram (A-0). The A-0 diagram shows the external interface for the x CMA Node 5. 
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Figure D-2. Extend CMA to Disconnected Node 5 (A0). The AO diagram shows the detailed interface of the CMA to Node 5. 
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Figure D-3. xCMA Connect with CMA (A1). The Al diagram details the interface between the subfunctions of the Connect with 
CMA function. 
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Figure D-3. Provide Collaboration within xCMA system (A2). The A2 diagram details the interface between the main functions of the 


xCMA system. 
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Figure D-4. Receive Information (A21). The A21 diagram drills down into the subfunctions of receive information function. 
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Figure D-6. xCMA System Send Information (A22). The A22 diagram drills down to the subfunctions of the Send Information 
function. 
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Figure D-7. xCMA System Display Information (A23). The A23 diagram drills down to the subfunctions of the Display Information 


function. 
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Figure D-7. xCMA Manage Information (A3). The A3 diagram drills down to the subfunctions of the Manage Information function. 
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APPENDIX E. QUALITY FUNCTIONAL DEPLOYMENT 


In an effort to facilitate responsiveness to customer requirements, a QFD diagram 
was performed. The development of the QFD ensures that all the customer requirements 
are identified and applied in the most appropriate manner to address the problem. The 
QFD results aided in a common understanding of requirements between all the 
stakeholders and identified the most important requirements to be met by the xCMA 
system. 

Once the QFD relationships were established, weighting factors were assigned to 
each of the requirements. The weighting factors identified the requirements that were 
used as MOEs for the system performance. The QFD also presented the customer 


requirements in engineering terms. 
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Figure E-1. QFD Representation of System Level Requirements. This QFD depicts the 


interactions between the system level requirements and relationship between the system level 


requirements and customer requirements. 


E-2 


System Level Requirements 







































































on oO Relationship: 
oO oO — © Strong 
. Medi 
oxo <== Blank No relationshi 
oxoxe xe = , 
Oo Oo oO = a = Interaction: 
oxoxoxox™ =-x<™" + Positive 
+ oO oxo0xo =<" oO ° Neutral 
+ ++x<o + + oO - oxo Negative 
extx<t xoxoxoxo xoxo Xo 
Xt xt xo xO x0 xO«OxO0 xo XO 
xt xx x0xOxOx<Oxo xoxo xO 
Xt xe x0 X#XOX0 XO XO XO XG 
x<txx +x<0<0x0 <0 XO XO X= <= 
XXX OX <OxK=<O XO XO XOXO XOX= Xe 
PE KF ox=<*Q <0 XO XOX XOX Xe 
ext ; OX KO XOXOXEXEKOKEa KE 
XX = XO KE KO x eX KOKO Ke KE XE KOK EX 
xXx 0 <a Xe Ka KOE KEKE KX 
¢ ¢ 3 ° o 2 g 2 a z 2 
Sp eeranl ees cee een Sell eral pe ea llies a lpreeme eereal |e al || seal ico = 
| (eet eels eee eel a) Peele leslie ee Se Flee |e 
FR | ee|28/ 8/88) 8] 2 ise) F | = |e8) & |s8/ 8) s |se/ 8] el] el al 
geo\/28/28| 2 jee] 2 | € |2=| 2) gs | ee| 3 |Se/ 5) 2 |2e/ 2) 2) 8] 2 | Ff 
s2/|8 | 8 3 | 8 2 2 a a 2 = ge a | 2 |e ao) 2 (& < 
© @ | |feSeel Pestana fetes eae See a/2|/% || & 
o 6 6 & ae je 3 8 é a /4 4 
Connect with CMA © © Oo} oe G©}O;}O;}0}] © 
Receive data and information © © © © © © [) ° ° . . . . 
Transmit data and information © O©|}|O;}O;] 90 
Display data and information . . . . ° © © © © . 
Manage Data and information . . . . e e . . . . . . . . © © © 
Provide unclassified collaboration ©/0O!101/0O];]O0O]}O0O;}O];]O]}]O0;}0]0] 0 . ° ° ° 
Provide open architecture design . ° ° ° ° ° 
Provide plug and play interface e . . ° ° ° ° ° 
Provide Graphical User Interface ©}| oe © © © 
Provide computer based training . . ©o|e] oe . . ©/eo;]o0/]90 O®/O;}0;}0/]0 
Provide remote trouble-shooting and 
eeenueactes cenoonnd ©|] oe . . . . . . . . . . . . . . 
Provide O-I-D preventive and corrective 
maintenance paradigm 
Povide Ao (0.9) ©1O1OlLOLOLOLOILOILOILO!LOILOLOLO!LO!]O}]O}]O}]O/|°9O 
Provide MTBF (1500 hrs) O©1}O;}O}OTOLOILOILOILO!LO;]O;L]O;]O;LO;]O;]O;]O;}]O}]O/;9O 
Operating Radius < 30 nmi ©/O;/0O;}]0O;}/0]0;]0 © 







































































Figure E-2. QFD Representation of System Functions and Subfunctions. 
interactions between the system functions and subfunction elements. Also, the QFD shows the 
relationship between the system level requirements and system functions and subfunctions. 
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This QFD depicts the 
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Figure E-3. QFD Representation of System Functions and Subfunctions and Evaluation 
Measures. This QFD depicts the interactions between the evaluation measure elements. The 
QFD also shows the relationship strength between the evaluation measures, and system functions 


and subfuntions. 
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APPENDIX F. ALTERNATIVES GENERATION 


Through research, brainstorming and brain-writing, a list of possible alternatives 
were considered. The alternatives were generated by focusing on the functional model 
and the QFD results, keeping in mind the requirements listed in each of these analysis. 
The initial set of alternatives was generated from a table of options. Options to meet the 
requirements were categorized into COMMS, a host system, host to communications 
interface, software services, PLI, display, identify, user interfaces, storage and 
deployability. The initial list of options is shown in Table F-1. From this set of options, 
alternatives were generated that make use of each of these options. The initial list of 


alternatives is shown in Table F-2. 


Table F-1. Initial List of Options 


HOST to COMMS - i a 
COMMS Host System iieriace Display Identify User Interfaces] Storage Deployability 
ar Tactical Internal 
INMARSAT(L-Band) Bik Roller Ealor 
Tactical External DGPS - Internal Internal 
KU Band SATCOM Router 








Commercial NIC (Network 
UHF SATCOM Internal Router Interface Card) 
Laptop : 
Multiple 
HF-LOS Commercial Displays 


External Router i 
Se External 
UHF-LOS DGPS - External 
Desktop : 
Tactical Internal 
VHF-LOS Modem IP Based i 
: GPS - External 
: Tactical External 
Wireless PC Based wee Remote 
(802.11/802.16) ecem 


Commercial 
TSAT Rack mounted SBCs Internal Modem bio recognition 


Readable in 
New Technology GPS - Internal bright light Removable 


Software Definable Mobile Terminal Commercial 
; : External Modem 
Radios Equipment Other Hardware |card reader 


Evaluation Criteria 


Properly interfaces 
between Host & Accuracy = +/- 10 24-48 hours of 
Bandwidth Scalable COMMS meters (HSI) Accuracy = 100% information 








Probability =90 
Range >= 30 Nm Plug & Play 


95% 


Search < 10s 
Maintainable 


Table F-1. This table represents the initial set of alternatives that were considered. The list was the result of research, brainstorming 
and brain writing techniques. 
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Table F-2. Preliminary List of xCMA System Alternatives 
































System Options 
Renee Host to 
ates COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
on Tactical 
1 TMS Digital Internal Do Color NIC Card Foy bound mole: Internal Man 
(L-Band) Assistant Internal and smart card reader 
Router 
(PDA) 
INMARSAT Tactical | DGps Touchscreen 
2 (L-Band) Laptop External Bical Monochrome IP Based ieadsee, aud camer External New Technology 
Router 
Commercial 
3 Dein Desktop Internal |GPS Extrnal LCD Other Keyboard, trackball, Remote Helo 
(L-Band) Hardware and bio-recognition 
Router 
Commercial : ae 
4 TMT PC Based External |GPS Internal} PLASMA aay oe recent, Removable Man/ship 
(L-Band) Technology mic and speakers 
Router 
Tactical : we 
5 INMARSAT |Rack Mounted acai New CRT IP Based Voice recognition, Nave Mania 
(L-Band) SBCs Technology and headset 
Modem 
Mobile Tactical : 
6 Me Terminal External |GPS Extrnal ee ae Rebead oe Internal Ship 
(L-Band) : Displays Hardware | and bio-recognition 
Equipment Modem 
Commercial Touchscreen, 
7 INN Rot None Internal Dore None None headset, and bio- Removable Helo 
(L-Band) External ar 
Modem recognition 
Commercial 
8 eta ey External None New NIC Card Be ybornd, wack bal New Technology None 
(L-Band) Technology Medan Technology and smart cad reader 



































F-3 








System Options 
























































Host to 
a COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Jasna! DGPS Keyboard, mouse 
9 KU Band PDA ean cen Color NIC Card baila heaped eadce Internal Man 
SATCOM ont 
Tactical 
DGPS Touchscreen, 
10 KU Band Laptop eats penal Monochrome IP Based heaisee and coment External New Technology 
SATCOM oe 
Commercial 
Other Keyboard, trackball, 
11 KU Band Desktop is GPS Extrnal LCD Hardware: || and biosrecapuition Remote Helo 
SATCOM Outer 
eormenal New Voice recognition. 
12 KU Band PC Based External |GPS Internal) PLASMA Technol — g k ; Removable Man/ship 
SATCOM Beater echnology | mic and speakers 
Tactical : 2 
13 KU Band — Internal oa CRT IP Based ss : saa o None Man/Helo 
SATCOM Modem al 
Mobile Tactical ‘ 
14 Terminal External |GPS Extrnal ee oe Keyboard, ae Internal Ship 
KU Band Equi Mod Displays Hardware | and bio-recognition 
SATCOM quipment odem 
Commercial DGPS Touchscreen, 
15 KU Band None Internal None None headset, and bio- Removable Helo 
Modem Ewe recognition 
SATCOM 2 g 
Commercial 
New New Keyboard, trackball, 
16 KU Band Techucloxy External None Technology NIC Card sid Ginn’ eadreader New Technology None 
SATCOM Modem 
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System Options 
























































Host to 
ia COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Tactical 
17 PDA Internal pore Color NIC Card Keyboard, mause, Internal Man 
UHF R Internal and smart card reader 
SATCOM Our 
Tactical 
DGPS Touchscreen, 
18 UHF Laptop eats penal Monochrome IP Based heaisee and coment External New Technology 
SATCOM One 
Commercial 
19 Desktop Internal |GPS Extrnal LCD one Beybend. mack ball, Remote Helo 
UHF R Hardware and bio-recognition 
SATCOM ome 
coe New Voice recognition. 
20 UHF PC Based External |GPS Internal) PLASMA Technol : a 8 k ; Removable Man/ship 
SATCOM Beater echnology mic and speakers 
Tactical . w: 
21 UHF — Internal oa CRT IP Based ss : a ae None Man/Helo 
SATCOM Modem ey ee 
Mobile Tactical ‘ 
22 Terminal External |GPS Extrnal ee oe Keyboard, ae Internal Ship 
UHF Equi Mod Displays Hardware | and bio-recognition 
SATCOM quipment odem 
Commercial DGPS Touchscreen, 
23 UHF None Internal Fea None None headset, and bio- Removable Helo 
SATCOM Modem recognition 
Commercial 
24 UHF aed External None New NIC Card Keynoed wockball, New Technology None 
Technology Technology and smart cad reader 
SATCOM Modem 
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System Options 
























































Host to 
ta COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Tactical DGPS Keyboard, mouse 
25 PDA Internal Color NIC Card y : : Internal Man 
R Internal and smart card reader 
HF-LOS outer 
Tactical 
26 Laptop External DGS Monochrome IP Based Teuehscie, External New Technology 
R. External headset, and camera 
HF-LOS outer 
Commercial 
27 Desktop Internal |GPS Extrnal LCD one Beybend. mack ball, Remote Helo 
R. Hardware and bio-recognition 
HE-LOS aia 
Sa New Voice recognition 
28 PC Based External |GPS Internal} PLASMA Technol nieantl 8 lee : Removable Man/ship 
HF-LOS Router aecnett Nr ere 
Tactical . wo 
29 — Internal T ne CRT IP Based a : saa ee None Man/Helo 
HF-LOS S Meson echnology and headse 
Mobile Tactical ‘ 
30 Terminal External |GPS Extrnal ee oe Keyboard, ae Internal Ship 
Baa uienk Vedens Displays Hardware | and bio-recognition 
HF-LOS ae 
Commercial DGPS Touchscreen, 
31 None Internal None None headset, and bio- Removable Helo 
Modem External recognition 
HF-LOS . e 
Commercial 
32 aed External None New NIC Card Keynoed wockball, New Technology None 
Technology Technology and smart cad reader 
HF-LOS Modem 
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System Options 
























































Host to 
ta COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Tactical 
33 PDA Internal pee Color NIC Card Keyboard, mause, Internal Man 
R Internal and smart card reader 
UHF-LOS dai 
Tactical 
34 Laptop External DGS Monochrome IP Based Teuehscie, External New Technology 
R. External headset, and camera 
UHF-LOS pUNEE 
Commercial 
35 Desktop Internal |GPS Extrnal LCD one Beybend. mack ball, Remote Helo 
R. Hardware and bio-recognition 
UHF-LOS One 
coe New Voice recognition 
36 PC Based External |GPS Internal) PLASMA Technol : a 8 k Removable Man/ship 
UHF-LOS Beater echnology mic and speakers 
Tactical . wo 
37 — Internal oa CRT IP Based ss : saa ee None Man/Helo 
UHF-LOS Modem By ee 
Mobile Tactical ‘ 
38 Terminal External |GPS Extrnal ee oe Keyboard, ae Internal Ship 
Eau; i Mod Displays Hardware and bio-recognition 
UHF-LOS quipmen odem 
Commercial DGPS Touchscreen, 
39 None Internal Focal None None headset, and bio- Removable Helo 
UHF-LOS Modem recognition 
Commercial 
40 aed External None New NIC Card Keynoed wockball, New Technology None 
Technology Technology and smart cad reader 
UHF-LOS Modem 
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System Options 
























































Host to 
ta COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Tactical 
41 PDA Internal pee Color NIC Card Keyboard, mause, Internal Man 
R Internal and smart card reader 
VHF-LOS Our 
Tactical 
42 Laptop External DGS Monochrome IP Based Teuehscie, External New Technology 
R. External headset, and camera 
VHF-LOS One 
Commercial 
43 Desktop Internal oe LCD Other Keyboard, trackball, Remote Helo 
R External Hardware and bio-recognition 
VHF-LOS OUNEE 
coe New Voice recognition. 
44 PC Based External |GPS Internal) PLASMA Technol eane anit - mae Removable Man/ship 
VHF-LOS Router aecnett P 
Tactical . w: 
45 — Internal oa CRT IP Based ss : saa i None Man/Helo 
VHF-LOS : Modem ey 
Mobile Tactical GPS Multiple Other Keyboard, mouse, ‘ 
46 Terminal External : é os Internal Ship 
Eau; i Maden External Displays Hardware and bio-recognition 
VHF-LOS ae 
Commercial DGPS Touchscreen, 
47 None Internal None None headset, and bio- Removable Helo 
Modem External recognition 
VHF-LOS . e 
Commercial 
48 aed External None New NIC Card Keynoed wockball, New Technology None 
Technology Technology and smart cad reader 
VHE-LOS i 
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System Options 
























































Host to 
a COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
: Tactical 
Wireless DGPS Keyboard, mouse, 
49 (802.11/802.16 PDA sn nbecual Color NIC Card aa aaprescleadce Internal Man 
) 
sh a L | ee IP Based TOuehecieen: External New Technol 
(802. 11/802.16 aptop oe External onochrome ase: headset, and camera xterna ew Llecnnology 
) 
: Commercial 
Wireless GPS Other Keyboard, trackball, 
ms (802.11/802.16 Deity oe External Pep Hardware and bio-recognition Rema a 
) 
ve commercial New Voice recognition. 
52 |(802.11/802.16} PC Based External |GPS Internal} PLASMA . g ; Removable Man/ship 
) Bonita: Technology | mic and speakers 
Wireless Tactical . we 
53 (802.11/802,16| 82K Mounted) temal New CRT ihiassa: | YO een, None Man/Helo 
) SBCs Meson Technology and headset 
Wireless Mobile Tactical GPS Multiple Other Keyboard, mouse, . 
54 (802.11/802.16 Terminal External : ‘ a Internal Ship 
. . Equipment eden: External Displays Hardware | and bio-recognition 
) 
Wireless Commercial DGPS Touchscreen, 
55 (802.11/802.16 None Internal Peal None None headset, and bio- Removable Helo 
Modem recognition 
) 
: Commercial 
Wireless New New Keyboard, trackball, 
96 |(802.11/802.16 Technology pte Bone Technology NIC Card | snd smart cad teader| Nw Technology None 
) 
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System Options 
























































Host to 
ta COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Tactical 
DGPS Keyboard, mouse, 
57 ‘Transforaatie PDA =a cen Color NIC Card baila heaped eadce Internal Man 
nal SATCOM sicaasd 
Tactical 
DGPS Touchscreen, 
28. | Teahofematio Laptop oe Balcaial Monochrome IP Based heaisee and coment External New Technology 
nal SATCOM ome 
Commercial 
GPS Other Keyboard, trackball, 
id Transformatio Desiop dios External Pep Hardware and bio-recognition Rema a 
nal SATCOM OUNEE 
commercial New Voice recognition. 
60 | Transformatio| PC Based External |GPS Internal) PLASMA Technol eane anit - mae Removable Man/ship 
nal SATCOM Router acunabes eee 
Tactical . we 
61 Transformatio a Internal T i CRT IP Based ss : saa i None Man/Helo 
nal SATCOM : Modem | “°""0}°8Y 
62 Panis aie GPS Multiple Other Keyboard, mouse, aa Shi 
Transformatio Eauj Mod External Displays Hardware | and bio-recognition P 
nal SATCOM | /4u!pment noe 
Commercial DGPS Touchscreen, 
62 | *Teanefemate None Internal Peal None None headset, and bio- Removable Helo 
nal SATCOM Modem recognition 
Commercial 
New New Keyboard, trackball, 
64 | Transformatio Technology pte None Technology Niet and smart cad reader Dene Tecmnelney None 
nal SATCOM aati 
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System Options 

































































Host to 
ee COMMS | Host System | COMMS PLI Display Identify User Interfaces Storage Deployability 
Interface 
Tactical 
Software DGPS Keyboard, mouse, 
65 Definsbile PDA ean cen Color NIC Card baila heaped eadce Internal Man 
Radios dai 
Ne Lapt cat | Dee. eee IP Based Toneiecteen: External New Technol 
Defnable aptop 2 Beamal onochrome ase fieadeet andicamnet xterna ew Technology 
Radios pUNeE 
Commercial 
Software GPS Other Keyboard, trackball, 
wy Definable Desitop Tene External Pep Hardware and bio-recognition Rema Help 
: Router 
Radios 
Sonate eommenial New Voice recognition. 
68 Definable PC Based External |GPS Internal) PLASMA . g ; Removable Man/ship 
: Technology mic and speakers 
Radios Router 
Software Tactical . we 
69 Definable Rock Mounted Internal New CRT IP Based NOL Seog None Man/Helo 
; SBCs Technology and headset 
Radios Modem 
Software a Pecue GPS Multiple Other Keyboard, mouse, 
70 Terminal External : é os Internal Ship 
Definable External Displays Hardware | and bio-recognition 
. Equipment Modem 
Radios 
Software Commercial DGPS Touchscreen, 
71 None Internal None None headset, and bio- Removable Helo 
Definable External 1 
Radias Modem recognition 
Commercial 
Software New New Keyboard, trackball, 
72 Deéfinable Techuclogy External None Technology NIC Card sid Giant eadreader New Technology None 
Radios Modem 
Table F-2. This table represents the alternatives that were generated as a result of the initial set of options as shown in Table F-1. 





Assumptions used to generate the initial list of alternatives are: 
- Commercial Satellite Communications will use Commercial router/modem 
- Military Satellite Communications will use Tactical router/modem; 
- Wireless will use a commercial router/modem 
- TSAT is a transformational satellite 


- Web based network Protocols are implemented 


Further research showed that IEEE 802.11 as well as all the LOS options do not 
meet the 30 nautical mile range requirement and are deleted from the alternatives [Javvin 


Network Management and Security, 2007]. 


Research further showed that INMARSAT does not handle the streaming video 
requirements. New technology will be discussed for future options, but will not be 
evaluated due to the lack of system specifications available for evaluation. Upon 
defining MTE it is determined that MTE is another form of a SBC. These two categories 


are combined. 


Keeping the above assumptions in mind and considering the restrictions found 
through research for other protocols and tactical equipment, an updated list of options 
was generated. The updated list of options is shown in Table F-3. From this list an 


updated list of alternatives was generated and is shown in Table F-4. 
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Table F-3. Updated List of xCMA System Options 
COMMS Host System Router/Modem pole are ~ PLI Display Identify 
Services 
SATCOM- Commercial 
DU COE 
TADIOP Commercial LCD MAC / IP Address 
Wirel 802.16 i : 
ireless ( or equiv) Specific 
Application 
S/W 
SATCOM - 
Military/Government Denn Tscinelocy CMA GPS 
Toolset 
Tactical New Technology he eae 
Software Definable SBC New Technology 
Radios Web based 
Common 
Operational 
Picture 
Evaluation Criteria 
Properly interfaces 
between Host & [Accuracy = +/- 
Bandwidth Scalable COMMS IN/A. 10 meters (HSD [Accuracy = 100% 
Range >= 30 Nm Plug & Play 
Portable 
Expandable 
Supportable 
Maintainable 


























Reliable 





restrictions identified in research. 
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Table F-3. This table represents the revised list of options that were generated as a result of the documented assumptions and 








Table F-4. Updated List of Alternatives 
















































































COMMS Host System Router/Modem PLI Display Identify 
SATCOM — Commercial Laptop Commercial GPS LCD MAC/IP 
SATCOM — Commercial New Technology Commercial GPS New Technology Other HW, new tech 
SATCOM — Commercial SBC Commercial GPS LCD MAC/IP 
SATCOM — Commercial Mobile Terminal Equipment Commercial GPS LCD Other HW, New Tech 
SATCOM - Military/Government Laptop Tactical GPS LCD MAC/IP 
SATCOM - Military/Government New Technology Tactical GPS New Technology Other HW, new tech 
SATCOM - Military/Government SBC Tactical GPS LCD MAC/IP 
SATCOM - Military/Government}| Mobile Terminal Equipment Tactical GPS LCD Other HW, New Tech 
Wireless 802.16 Laptop Commercial GPS LCD MAC/IP 
Wireless 802.16 New Technology Commercial GPS New Technology Other HW, new tech 
Wireless 802.16 SBC Commercial GPS LCD MAC/IP 
Wireless 802.16 Mobile Terminal Equipment Commercial GPS LCD Other HW, New Tech 
Software Defined Radio Laptop Commercial GPS LCD MAC/IP 
Software Defined Radio New Technology Commercial GPS New Technology Other HW, new tech 
Software Defined Radio SBC Commercial GPS LCD MAC/IP 
Software Defined Radio Mobile Terminal Equipment Commercial GPS LCD Other HW, New Tech 





This table represents the revised list of alternatives that were generated as a result of the revised options as shown in Table F-3. 
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With the intent to provide foreign allies and merchant vessels the xCMA system, 
and understanding that restrictions exist in the use of tactical equipment, all tactical 
equipment was eliminated from the list of alternatives. SDRs are network agnostic, thus 
the implementation and use of SDRs require an communications system, i.e. 802.16m 
wireless or SATCOM. Given this restriction, SDRs were eliminated from the list of 


alternatives. 


Zwicky’s Morphological Box 

The development of alternatives identified four primary alternatives and a non 
materiel solution. These options are used to determine the system designs by selecting 
different tracks. They are listed below and graphically in Table G-5 known as Zwicky’s 
Morphological Box. 


e Non Materiel - Change CONOPS; use the existing networks and infrastructure. 
Modify mission responsibilities and operational concepts. 

e Develop aSATCOM-Laptop system using existing commercial SATCOM with a 
COTS laptop. 

e Develop aSATCOM-SBC system using existing commercial SATCOM with a 
SBC MTE. 

e Develop a Wireless-Laptop system using 802.16m wireless protocols with a 
COTS laptop. 

e Develop a Wireless -SBC system using 802.16m wireless protocols with a SBC 
MTE. 
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Table F-5. Zwicky’s Mophological Box of possible xCMA system alternatives. 


System Functions 


COMMS Router/Modem PLI Display Identify 











es CoTS =) cps LCD ——JC MAC Add 
(wietinan cer / ee 
Wireless 802.164 SBC MTE 


[Wireless SBC _ ‘i —— — 





Non Materiel 











Table F-5 identifies four primary alternatives and a non materiel solution. These options 
were used to determine the system designs. This representation of system alternatives is 
a systems engineering tool known as Zwicky’s Morphological Box. 


This colorfully illustrates the creation of each xCMA system candidate. Different 
system attributes are selected from left to right under the System Functions title box. 
Mixing and matching the different attributes generates combinations of options for each 


alternative. 


The non-materiel solution uses the existing networks and_ infrastructure. 
Modification of mission responsibilities, operational concepts and technologies would not 
provide adequate CMA connectivity to the disconnected vessel or user. Limited 
connectivity could be provided on an adhoc basis using existing UHF/VHF radio 
telephones and possibly messenger services (small boat and helicopter delivery of maps, 
orders). This does not provide the capability for Node 5 to effectively and efficiently 
communicate with the humanitarian operation vessels using streaming video, text, 
pictures, e-mail, and chat. Since this solution does not meet the requirement it is 
eliminated from the list of alternatives. The final list of alternatives is shown in Table F- 
6. 
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Table F-6. Final List of xCMA system alternatives 














al SATCOM - Commercial Laptop Commercial GPS LCD MAC/IP 
on SATCOM - Commercial Integrated SBC (MTE) Commercial GPS LCD MAC/IP 
3. Wireless- . ; 

i Wireless 802.16 Laptop Commercial GPS LCD MAC/IP 
aptop 

oe Wireless 802.16 Integrated SBC (MTE) Commercial GPS LCD MAC/IP 
































Table F-6 provides the final list of alternatives generated. 
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APPENDIX G. RELIABILITY MODELING 


The QFD results show reliability to be of major concern in the selection of the 
xCMA system. Since reliability has a very high rating factor, modeling and simulation is 


applied to determine the reliability of each of the four proposed alternatives. 


A mathematical model was constructed using Microsoft Excel. To properly 
calculate a 95% confidence interval and reduce errors in the simulation process, the 


model is constructed using 300 replications. 


Table G-1 detailed the source of MTBF values used in the simulation. As part of 
the reliability simulation actual values for MTBF are used on existing systems. A 
simulation summary is given for each of the alternatives in Tables G-2 through G-5. 
Table G-2 shows the detailed summary for Alternative 1 -- SATCOM-Laptop. Table G-3 
shows the detailed summary for Alternative 2 -- SATCOM-SBC. Table G-4 shows the 
detailed summary for Alternative 3 -- Wireless-Laptop. Table G-5 shows the detailed 
summary for Alternative 4 -- Wireless-SBC. The xCMA system reliability for each 


alternative is shown in Table G-6. 


Table G-1. Manufacturers’ published MTBF values and Calculated Reliabilities 


Reliability 
-1/MTBF for ~14 
days 


rr WY, - . > 7 
Ho : [10,000] | [70.000] —(0.000700000)] 0-5 
Router/Modem: Commercial | 1868.10] 1,128,220] 586,683] 706,709] 300,000] 342,000] 876,000] _350,000[ | 660,089] (0.00000TST5)[___7.09 
Display:tcD SS C*T «v0 _——mescoo’ SST] dT SST «i | 22,500] (0.000084) 


Avgerage 


Celt Sete Muieta 


1128, 223) 566,683] 706,708] 300,000] 342,000] 316,000] — 360,000] 
Display: LCD [200001 soo ——s| S| ST TT S| ‘| __ 22,500] 0.0000840] 0.08 
















[660,088] —(0.000007575)| 1.09 
Display: LCD [20,000 25001 «| | «| ‘| ——*+i{___ |__| _ 22500 _(o.0000aeaaay|___0.99 


Router/Modem: Commercial 1,556,100| __1,123,223[ 586,683] 706,709| _300,000| _342,000[ 316,000] 350,000 si 





Host System: Single Board Computer (MTE y —|144,036] _(0.000006043)| 1.00] 
[Router/Modem: Commercial __—=—=~S~—=*d;~_~, 806,100] 1,123,223] 686,683] 706,709] 300,000] 342,000] 316,000] 360,000] | 660,089] _(0.000001515)| 1.00] 





Display:tcD SS SC~d «0 _—SC! SCS TTT ST (YY ~—_22,500] (0.000088848)] 0.99] 


Table G-1 provides a summary of manufacturers’ published MTBF values obtained from research of similar systems. The MTBF 
values for each component are averaged and used to calculate the component reliability. 
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Table G-2. Reliability Simulation for xCMA System Alternative 1: SATCOM-Laptop 


Summary Replications 


eredi Teall} 


ered) seul} 


yst m: | Router/Modet a r 
i : os | 


[905% | sane | 
[99.95% | 98.48% | 
[99.95% | _98.54% | 
[99.95% | 98.51% | 
[99.95% | 98.51% | 
[99.95% | 98.53% [_ 
[99.95% | 98.50% | 
[99.95% | __98.49% | _ 
[99.95% | 98.52% | 
[99.95% | 98.55% | 
[99.95% | 98.52% [_<¢ 
[99.95% | 98.50% | 
[99.95% | 98.50% | 
[99.95% | 98.53% | 
[99.95% | 985% | 
[99.95% | _ 98.40% [_¢ 
[99.98% | 98.57% | 
[99.95% | _9851% | 
[99.95% | 98.54% | 
[99.95% | 98.52% |_ 
[99.95% | 98.53% | 
[99.95% | 98.50% | 
[99.95% | _easi% | 
[99.95% | sasi% | 
[99.95% | 98.52% | 
[99.95% | 98.54% [1 
[99.95% | sasi% | 
[99.95% | 98.52% |< 
[99.95% | __9852% [1 
[99.95% | 98.40% | 
[99.95% | 98.52% |< 
[99.95% | _9852% [1 
[99.95% | 98.53% | 
[99.95% | 98.50% | _< 
[99.95% | 9854% | 
[99.95% | 98.55% | 
[99.95% | 98.50% | 
[99.95% | 98.50% | 
[99.05% | 9854% | 
[99.95% | 98.53% | 
[29.05% | sas] S 
[99.95% | 98.53% | 
[99.95% | 98.52% |_9 
[99.95% | 98.50% | 
[99.95% [98.53% | 











Router/Modem: 
Commercial 


lAvgerage MTBF 660,089 22,500 | 
-1/MTBF ).0C -0.000002 -0.000044 
Reliability for ~14 days ; | f 99.95% 98.55% 


System / Component Survive? 


Display: LCD 














1 Replication 


Coes Kez CAE Seis 


; 
300 
Replications 


Conf Width of Reliability Ol ‘a 0.0001% 0.0021% 
Cl Low of Average Reliability 99.95% 98.52% [ 
Cl High of Average Reliability Ne / 99.95% 98.52% 


System / Component Survive? 








Table G-2 summarizes the reliability simulation results for SATCOM-Laptop combination. 
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Table G-3. Reliability Simulation for xCMA System Alternative 2: SATCOM-SBC 


Summary Replications 


Components 


Components 













Router/Modem: 
Commercial 


Router/Moder 
Commercial 


rd Display: LCD Display: LCD 





[S585 [saa] 
[99.95% | 98.52% | 
[99.95% | _98s2% _[_& 
[99.95% [98.53% | 
[99.95% [985% | 
[99.95% | 98.51% | | 
[99.95% | 98.53% —|__ 
[99.95% [98.55% | 
[99.95% | 985% | 
[99.95% | 98.52% | 
[99.95% | saaa% | 
[99.95% | 98.50% | 
[99.95% | 98.54% | 
[99.95% | 98.52% | 
[99.95% | 98.55% | 
[99.95% [98.52% | 
[99.95% | _9853% 
[99.95% [985% |[_8 
[99.95% | 98.57% | 
[99.95% | 98.49% | — 
[99.95% | 98.56% | 
[99.95% | 98.50% | 
[99.95% | 98.55% | 
[99.95% | 98.50% | _& 
[99.95% | 98.54% | 
[99.95% | 98.40% | 
[99.95% | 985% | 
[99.95% | 985% | 
[99.95% | 98.50% | 
[99.95% | sasa% | 
[99.95% | 98.54% | 
[99.95% | 98.52% | 
[99.95% | sas1% | 9 
[99.95% | sasi% | 
[99.95% | sas% | 
[99.95% | 98.50% | 9 
[99.95% | 9a5a% | 
[99.95% | 98.53% | 
[99.95% | 98.53% | 9 j 
[99.95% | 98.54% | 98.76% 
[99.95% | sasa% | 

[99.95% | 98.53% | 
[99.95% | 98.50% | 9 
[99.95% | 98.55% | 
[99.95% | 98.51% | 







Avgerage MTBF 
-1/MTBF ] -0.000044 
Reliability for ~14 days Es 


System / Component Survive? 


1 Replication 


Co 2 ROLE SOs 


Num of Replications 00° 
Average Reliability I 99.95% 
SD of Reliability 


[0.00% 
300 5 95% 95% 
Replications 5% 5% | 
00482 o0001% | 0.0027% 
96.357 99.95% 98.52% 
96.367 99.95% 98.52% 


System / Component Survive? 








Table G-3 summarizes the reliability simulation results for the SATCOM-SBC combination. 
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Table G-4. Reliability Simulation for xCMA System Alternative 3: Wireless-Laptop 


Summary 






ered alu cy 


Router/Modem: 


Commercial Display siEC 






Avgerage MTBF 


-1/MTBF -0.000002 -0.000044 
Reliability for ~14 days g / 99.95% 98.52% | 


System / Component Survive? 


1 Replication 


300 
98.95% 
0.00% 
300 
Replications 


System / Component Survive? 













Replications 


Components 






Router/Moder 


Commercial Bigpley ECD 








[99.95% | 985% | _ 
[99.95% | 985% | 8 
[99.95% | 98.50% | 
[99.95% | __9851% |< 
[99.95% | 983% | 
[99.95% | 98.50% [_< 
[99.95% | 98.52% | 
[99.05% | 98.54% | 
[99.95% | 9.50% [_<¢ 
[99.95% | 98.52% | 
[99.95% | 98.54% | 
[98.95% | 98.53% | 
[99.95% | __985™% [_ 
[99.95% | _98.53% | 
[99.95% | 98.53% | 
[99.95% | 98.52% | 
[99.95% | 98.53% | 
[99.95% | 98.52% | 
[99.95% | 985% | 8 
[99.95% | 983% | 
[99.95% | 98.49% [_ 
[99.95% | 98.49% | 
[99.95% | 983% | 
[99.95% | 953% | 
[99.95% | 98.54% [8 
[99.95% | 954% | 
[99.95% | 98.53% | 
[99.95% | 98.52% [8 
[99.95% | 98.52% | 
[99.95% | 98.53% | 
[99.95% | 985% | 8 
[99.95% | _9asi% | 
[99.95% | 98.55% | 
[99.95% | 98.53% | 
[99.95% | 98.53% | 
[99.05% | 98.56% | 
[99.95% | 98.50% | 
[99.95% | 98.48% | 
[99.95% | 98.52% | 
[99.95% | 98.50% | 
[99.95% | 98.52% —[_ 


ees IKKE IOs 


Table G-4 summarizes the reliability simulation results for the Wireless-Laptop combination. 


Table G-5. Reliability Simulation for xCMA System Alternative 4: Wireless-SBC 


Summary Replications 


eredi eal} 


Components 


Router/Mode! Fi , Beene 
= ee | ae 












Router/Modem: 


rd Gominerciall Display: LCD | Iden’ MACIIF 










Prgerage MTBF BOUVET | 25500 | 5 
1 Replication -0.000002| “0.000044 99.95% | 98.54% | 
a7 99.95% | 98.50% [99.95% [98.49% | 


[99.95% | _985T% | 
[99.95% | 98.54% | | 
[99.95% | easi% [_< 
[99.95% | 98.56% | 
[99.95% | _98.50% | 
[99.95% | 985% | 
[99.05% | 984% | 
[99.95% | 98.50% | 
[99.95% | 985% | 
[99.95% | 982% | 
[99.95% | 98.50% | 
[99.95% | 98.55% | 8 
[99.95% | 98.49% | 
[99.95% | _98.53% | 
[99.95% | _9857% |< 
[99.95% | 98.50% | 
[99.95% | 98.53% | 
5% | 99.95% | 98.52% 
[99.95% | 98.50% | 
[99.95% | 98.50% | 
[99.95% | 985% | 
[99.95% | 98.50% | 
[99.05% | 98.40% [_< 
[99.95% | 98.54% | 
[99.95% | 98.49% | 
[99.95% | 98.53% | 
[99.95% | 98.40% | 
[99.95% | 9851% | 
[99.05% | 98.52% | _< 
[99.95% | 98.53% | 
[99.95% | 98.53% | 
[99.05% | 98.53% | 
[99.95% | sasi% | 
[99.95% | 98.52% | _ 
[99.95% | 98.53% | 
[99.95% | 98.49% | 
[99.95% | sasi% | 
[29.95% | 9.52%] 
[99.95% | 98.52% |_% 
[99.95% | 98.53% | 
[99.95% | 98.51% | 
[99.05% | 98.51% | 


System / Component Survive? | 


Co Ke OA IRs 


Num of Replications 
Average Reliability 
SD of Reliability 


300 
Replications 





System / Component Survive? 





Table G-5 summarizes the reliability simulation results for Wireless-SBC combination. 
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Table G-6. xCMA System Reliability Simulation Results 


Reliability 
-1/MTBF for ~14 
ar (EWE 


Conf Width ClLow of Cl High of 
Conf Level Alpha Average Average 
Reliability 


Avgerage 
MTBF 


Num of Average SD of 
oer Mm aE NMC iNg 


Component System pS Cli} 


10) heen) Component Survive? Reliability MTBF (hrs) 


Lapto io | | | eral | 

Router/Modem: Commercial 660,089] (0.000001515)[_ 1.00 300 99.95% | 0.0006% 95% 0.0001% | 99.95% | 99.95% 

Display: LCD 22,500] — (0.000044444)| 0.99 300 98.52% | 0.0182% 95% 0.0021% | 98.52% | 98.52% 
|\F | OC ] ) ( ¢ % 9 1% | h 

| 


| ie | | 


ale E er (M 44,036 (0.0 | ___ 1.00] ; | 95% | 5% | » | 99.77% | 99.77% | Yes _| 

I | L L | 

Router/Modem: Commercial 660,089] (0.000001515)| 1.00] +300 99.95% | 0.0006% 95% 0.0001% | 99.95% | 99.95% 

Display: LCD 22,500] (0.000044444)| 0.99300 98.52% | 0.0182% 95% 0.0021% | 98.52% 
S [IF 4 4 | \ 3 | \ of, y y y 


V1 | 


(0.000001515 -00 300 | 99.95% 0.0006% 95% | 5% | 0.0001% | 99.95% 99.95% 
(0.000044444) 0.99 300 98.52% 0.0167% 95% 5% 0.0019% 98.51% 98.52% 





stem: S z 1pu 4 ( | 1.00] 0.0029% [5% | o | 99.77% | 99.7 [ es 
Router/Modem: Commercial 660,089] (0.000001515)| 1.00 0.0006% 0.0001% | 99.95% | 99.95% 
Display: LCD 22,500{ _(0.000044444)| 0.99300 98.52% | 0.0178% 95% 0.0020% | 98.52% | 98.52% 

















Table G-6 provides a summary of the xCMA system reliability simulation results. These results are based on 300 replications with 
95% confidence level. 
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APPENDIX H. THROUGHPUT MODELING 


A mathematical model was constructed using Microsoft Excel. A summary of the 
mathematical model results for the SATCOM Laptop and SATCOM SBC options is shown in 
Figure H-1. A summary of the mathematical model results for the Wireless Laptop and Wireless 
SBC options is shown Figure H-2. To properly calculate a 95% confidence interval and reduce 
errors in the simulation process, the model is constructed using 30 replications for each of the 
listed alternatives, which are then repeated in a set of 500 totaling 15,000 replications. The 
simulation results for the SATCOM Laptop and SATCOM SBC are listed in Table H-1. 
Simulation results for the Wireless alternatives are listed in Table H-2. Immediately following 


the summary are detailed results for the 500 replications. 


H-1 


M/M/s 
Arrivalrate(Kbps) [| — 128 | Assumes Poisson process for 


Service rate (Kbps) | —.235 | arrivals and services. 


Number ofservers [| —__11| 


Utilization 54.47% 


P(0), probability that the system is empty 0.4553 
Lq, expected queue length 0.6516 
L, expected number in system 1.1963 


Waq, expected time in queue 0.00509 


W, expected total time in system (sec) 0.00935 


Probability that data waits to be processed 1.36% 


0.15 


ity 
oO 


Probabil 
Oo 
Oo 
oO 


oO 


9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 99 
NUMBER IN SYSTEM 





Figure H-1. Mathematical model results for SATCOM-Laptop and SATCOM-SBC systems. This figure captures the results from the 
mathematical model for SATCOM- Laptop and SATCOM-SBC systems. 


M/M/s 
Arrivalrate (Kbps) | — 128] Assumes Poisson process for 
Service rate (Kbps) 3,729 arrivals and services. 


Number of servers | 11 


Utilization [3.43%] 
P(0), probability that the system is empty 0.9657 
Lq, expected queue length 0.0012 
L, expected number in system 0.0355 


Wq, expected time in queue 0.00001 


W, expected total time in system 0.00028 
Probability that data waits to be processed 0.05% 


Probabili 


12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 99 
NUMBER IN SYSTEM 





Figure H-2. | Mathematical model results for 802.16 Wireless-Laptop and 802.16 Wireless -SBC systems. 


This figure captures the results from the mathematical model results for Wireless-Laptop and Wireless-SBC systems. 


Table H-1. Throughput Simulation for xCMA System Alternatives 1 and 2: SATCOM-Laptop and SATCOM-SBC 


Single Server Queue Data Table 
Calculations set to Manual. Press F9 to recalculate. 


Time between Average % | Utilization 
arrivals Arrival time Start service | Service time End service Wait time Idle Time 
0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00% 
0.01034 0.01034 0.01034 0.00186 0.01219 0.00000 8 15.24% 
0.00305 0.01338 0.01338 0.00005 0.01343 0.00000 
0.01102 0.02440 0.02440 0.00022 0.02463 0.00000 
0.00485 0.02925 0.02925 0.00311 0.03237 0.00000 
0.00097 0.03022 0.03237 0.00602 0.03839 0.00215 
0.00589 0.03612 0.03839 0.00325 0.04164 0.00227 
0.00138 0.03749 0.04164 0.00393 0.04556 0.00414 
0.02365 0.06115 0.06115 0.00250 0.06365 0.00000 st Based on 1 replication: 

0.01237 0.07352 0.07352 0.00196 0.07547 0.00000 L Num of Packets 500 
0.00676 0.08028 0.08028 0.00378 0.08406 0.00000 s Average wait time (sec) 0.00276305 
0.00372 0.08400 0.08406 0.00264 0.08670 0.00006 6 f SD of Average wait time 0.00482715 
0.00364 0.08764 0.08764 0.00096 0.08860 0.00000 E Conf Level 95% 
0.01119 0.09883 0.09883 0.00101 0.09984 0.00000 6! e Alpha 5% 
0.00847 0.10730 0.10730 0.00528 0.11258 0.00000 x Conf Width of Average wait time (sec) 0.0004231 
0.00070 0.10801 0.11258 0.00271 0.11528 0.00457 6 i Cl Low of Average wait time (sec) 0.0023399 
0.00982 0.11782 0.11782 0.00303 0.12086 0.00000 i Cl High of Average wait time (sec) 0.0031862 
0.00158 0.11940 0.12086 0.00273 0.12359 0.00146 6: E Num of PDs 500 
0.00813 0.12753 0.12753 0.00100 0.12852 0.00000 u Average Utilization Rate 48.55% 
0.00086 0.12839 0.12852 0.00764 0.13616 0.00014 R SD of Average Utilization Rate 4.38% 
0.00027 0.12866 0.13616 0.00221 0.13837 0.00751 i Conf Level 95% 
0.00092 0.12958 0.13837 0.00064 0.13902 0.00880 H Alpha 5% 
0.00380 0.13337 0.13902 0.00118 0.14020 0.00565 5 E Conf Width of Average Utilization Rate 0.38% 
0.00118 0.13455 0.14020 0.00175 0.14195 0.00564 f Cl Low of Average Utilization Rate 48.17% 
0.00147 0.13602 0.14195 0.01095 0.15289 0.00592 5 a Cl High of Average Utilization Rate 48.93% 
0.00115 0.13717 0.15289 0.00640 0.15930 0.01572 Probability that data waits to be processed 0.43% 
0.02826 0.16543 0.16543 0.00391 0.16935 0.00000 
0.01119 0.17662 0.17662 0.00191 0.17854 0.00000 i Based on 30 replications: 
0.00425 0.18087 0.18087 0.01503 0.19591 0.00000 5 ie Num of Replications 30 
0.00983 0.19070 0.19591 0.00477 0.20067 0.00521 : Average wait time (sec) 0.0048588 
0.00665 0.19735 0.20067 0.00344 0.20411 0.00332 4 A SD of Average wait time 0.0011322 
0.00156 0.19891 0.20411 0.00083 0.20494 0.00521 Hl Conf Level 95% 
0.00493 0.20383 0.20494 0.00908 0.21402 0.00111 4 & Alpha 5% 
0.00797 0.21180 0.21402 0.00084 0.21486 0.00222 g Conf Width of Average wait time (sec) 0.0004051 
0.00206 0.21386 0.21486 0.00017 0.21503 0.00101 4 5 Cl Low of Average wait time (sec) 0.0044537 
0.01642 0.23027 0.23027 0.00251 0.23278 0.00000 - Cl High of Average wait time (sec) 0.0052640 
0.00828 0.23855 0.23855 0.00069 0.23925 0.00000 5 lh Num of Replications 30 
0.00930 0.24786 0.24786 0.00046 0.24832 0.00000 i Average Utilization Rate 55.01% 
0.00586 0.25371 0.25371 0.00236 0.25607 0.00000 4 SD of Average Utilization Rate 3.77% 
0.00205 0.25576 0.25607 0.00505 0.26112 0.00031 Conf Level 95% 
0.00364 0.25940 0.26112 0.01224 0.27336 0.00173 N Alpha 5% 
0.01180 0.27119 0.27336 0.00291 0.27627 0.00216 4 ti Conf Width of Average Utilization Rate 1.35% 
0.00371 0.27491 0.27627 0.00169 0.27796 0.00137 i Cl Low of Average Utilization Rate 53.66% 
0.00882 0.28373 0.28373 0.01405 0.29779 0.00000 4 : Cl High of Average Utilization Rate 56.35% 
0.00169 0.28543 0.29779 0.00392 0.30170 0.01236 x Probability that data waits to be processed 0.43% 
0.00967 0.29509 0.30170 0.00016 0.30186 0.00661 
46 0.00848 0.30357 0.30357 0.00071 0.30428 0.00000 0.0017 46% 53.75% | robability that the system throughput = 1 


Avg wait time Utilization 
(sec) 
0.0027630 
0.0062309 
0.0046781 
0.0054543 
0.0048863 
0.0080646 
0.0044976 
0.0061575 
0.0035393 
0.0039510 
0.0038888 
0.0040340 
0.0041 
0.0057 
0.0050 
0.0040 
0.0048 
0.0073 
0.0046 
0.0062 
0.0052 
0.0040 
0.0047 
0.0052 
0.0052 
0.0044 
0.0052 
0.0032 
0.0045 
0.0045 


o 


Arrival Distribution: Exponential 
=- (1/ up )*LN(rand()) 
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Table H-1 summarizes the xCMA throughput simulation results using the single server queue excel spreadsheet model for the SATCOM- 
Laptop and SATCOM-SBC alternatives. 


H-4 


Table H-2. Throughput Simulation for xCMA System Alternatives 3 and 4: Wireless-Laptop and Wireless-SBC 


Single Server Queue Data Table 
Calculations set to Manual. Press F9 to recalculate. 


Time between Average % | Utilization Utilization 
arrivals Arrival time Start service | Service time | End service Wait time Idle Time Avg wait time 


0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 K Arrival Distribution: Exponential 0.00000879 


0.00897 0.00897 0.00897 0.00026 0.00923 0.00000 9 : 0.00001142 -23%| 
0.01098 0.01995 0.01995 0.00147 0.02142 0.00000 ; 0.00000866 
0.02646 0.04640 0.04640 0.00079 0.04720 0.00000 9 : 0.00000446 25% 
0.00345 0.04985 0.04985 0.00008 0.04993 0.00000 ! 0.00000794 07% 
0.00140 0.05125 0.05125 0.00138 0.05263 0.00000 9 d 0.00000748 


0.00223 0.05348 0.05348 0.00026 0.05374 0.00000 id 3,729 Kbps 0.00000733 
0.00508 0.05855 0.05855 0.00031 0.05887 0.00000 9 ie 0.00000336 id | 
0.00096 0.05951 0.05951 0.00021 0.05973 0.00000 i 0.00000710 

0.01878 0.07829 0.07829 0.00006 0.07836 0.00000 5 Num of Packets 500 0.00000472 
0.00327 0.08156 0.08156 0.00039 0.08196 0.00000 is Average wait time (sec) 0.00000879 0.00001090 
0.00707 0.08864 0.08864 0.00015 0.08879 0.00000 9. fu SD of Average wait time 0.00005519 0.00000830 
0.00757 0.09620 0.09620 0.00029 0.09649 0.00000 fu ‘Conf Level 95% 0.00000696 
0.01365 9 Alpha 5% 0.00001302 
0.00278 ! ‘Conf Width of Average wait time (sec) 0.0000048 0.00001268 
0.01091 0.12354 0.12354 0.00006 0.12360 0.00000 9. i ‘Cl Low of Average wait time (sec) 0.0000040 0.00000753 
0.00067 0.12421 0.12421 0.00027 0.12448 0.00000 2 Cl High of Average wait time (sec) 0.0000136 0.00000736 
0.00746 0.13167 0.13167 0.00003 0.13170 0.00000 9. ‘ Num of PDs _0.00000498 
0.00312 0.13480 0.13480 0.00001 0.13481 0.00000 f Average Utilization Rate 0.00000849 
0.00164 0.13643 0.13643 0.00003 0.13646 0.00000 if SD of Average Utilization Rate 0.00001202 
0.01074 0.14717 0.14717 0.00022 0.14739 0.00000 iS ‘Conf Level 0.00000219 
0.00671 0.15388 0.15388 0.00013 0.15401 0.00000 : Alpha 0.00000913 
0.00336 0.15724 0.15724 0.00018 0.15742 0.00000 9 i Conf Width of Average Utilization Rate 0.00000552 
0.00489 0.16213 0.16213 0.00013 0.16226 0.00000 2 Cl Low of Average Utilization Rate 0.00000661 
0.00136 0.16349 0.16349 0.00054 0.16403 0.00000 9 \ Cl High of Average Utilization Rate 0.00000690 
0.01270 0.17620 0.17620 0.00004 0.17624 0.00000 i Probability that data waits to be processed 0.00001028 
0.02594 9 I 0.00000765 
0.00606 0.20820 0.20820 0.00113 0.20933 0.00000 ! 0.00000702 
0.00094. 0.20914 0.20933 0.00048 0.20981 0.00019 9 & Num of Replications 30 0.00001740 
0.00209 0.21123 0.21123 0.00022 0.21144 0.00000 : Average wait time (sec) 0.0000081 0.00000832 
0.01765 0.22887 0.22887 0.00064 0.22951 0.00000 9 i SD of Average wait time 0.0000031 

0.00885 0.23772 0.23772 0.00014 0.23786 0.00000 ie ‘Conf Level 95% 

0.00229 9 i Alpha 5% 

0.00525 t Conf Width of Average wait time (sec) 0.0000011 

0.00270 0.24795 0.24795 0.00024 0.24819 0.00000 9 a Cl Low of Average wait time (sec) 0.0000070 

0.01316 0.26111 0.26111 0.00103 0.26214 0.00000 i Cl High of Average wait time (sec) 0.0000093 

0.00485 0.26596 0.26596 0.00006 0.26602 0.00000 9 i Num of Replications 

0.00384 0.26979 0.26979 0.00003 0.26982 0.00000 t Average Utilization Rate 

0.00077 0.27056 0.27056 0.00037 0.27093 0.00000 2 SD of Average Utilization Rate 

0.02161 0.29218 0.29218 0.00060 0.29277 0.00000 " ‘Conf Level 

0.00832 0.30050 0.30050 0.00018 0.30068 0.00000 r Alpha 

0.02616 0.32665 0.32665 0.00004 0.32669 0.00000 9 z ‘Conf Width of Average Utilization Rate 

0.01502 0.34168 0.34168 0.00004 0.34172 0.00000 y Cl Low of Average Utilization Rate 

0.00733 0.34901 0.34901 0.00007 0.34908 0.00000 9 z Cl High of Average Utilization Rate 

0.01018 i Probability that data waits to be processed 

0.00915 
0.01537 0.38370 0.38370 0.00015 0.38385 0.00000 i Probability that the system throughput > 128 Kbr 









































































































































Table H-2 summarizes the xCMA throughput simulation results using the single server queue excel spreadsheet model for the Wireless- 
Laptop and Wireless-SBC alternatives. 
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LIST OF ACRONYMS 


a AS 
Automatic Identification System 
Area of Interest 


-B- 


aCe 
Command and Control 
Command, Control, Communications, Computers, Intelligence 
Surveillance Reconnaissance 
Capabilities Based Assessment 
Computer Based Training 
Combined Enterprise Regional Information Exchange System 
Comprehensive Maritime Awareness 
Chief of Naval Operations 
Center of Excellence 
Community of Interest 
Communications 
Command Pacific Fleet 
Concept of Operations 
Continental United States 
Commercial-Off-The-Shelf 
Central Processing Unit 
Cathode Ray Tubes 


-D- 

Differential Global Positioning System 

Deputy Assistant Program Manager 

Dynamic Enterprise Integration Platform 

Differential GPS 

Department of Defense 

Department of Defense Architecture Framework 
Department of State 

Doctrine, Organization, Training, Materiel, Leadership and 
Education, Personnel, and Facilities 


2< 
Experimental Campaign Plan 


2h = 
Federal Aviation Administration 
Functional Flow Block Diagram 
Future Years Defense Plan 


GMCOI 
GMI 
GMII 
GMSA 
GPS 
GUI 


Hrs 
HSPD 
HSI 


IDEFO 
IEEE 
IP 

IPR 


JCTD 
JFC 
JOA 
JOC 


LCD 
LOS 
LRIT 


M&S 
MAC 
MAUT 
Mbps 
MDA 
MHQ 
MIEM 
MIFCLANT 
MIFCPAC 
MLS 
MOC 
MODEM 


Gs 
Global Maritime Community of Interest 
Global Maritime Intelligence 
Global Maritime Intelligence Integration 
Global Maritime Situational Awareness 
Global Positioning System 
Graphical User Interface 


LHe 
Hours 
Homeland Security Presidential Directive 
Human System Interface 


ois 
Integration Definition for Function Modeling 
Institute of Electrical & Electronics Engineers 
Internet Protocol 
In-Progress Review 


eipe 
Joint Capabilities Technology Demonstration 
Joint Forces Command 
Joint Operations Area 
Joint Operations Center 


=e 
Liquid Crystal Display 
Line of Sight 
Long Range Identification and Tracking 


-M- 
Modeling and Simulation 
Media Access Control 
Multi-Attribute Utility Theory 
Megabytes per second 
Maritime Domain Awareness 
Maritime Headquarters 
Maritime Information Exchange Model 
Maritime Intelligence Fusion Center Atlantic 
Maritime Intelligence Fusion Center Pacific 
Multi-Level Security 
Maritime Operations Center 
Modulator Demodulator 


MOE 
MOP 
MOTR 
MSPCC 
MTBF 
MTE 


NAVEUR 
NIC 
NMIC 
NORAD 
NPS 
NSMS 
NSPD 


OV 


PDA 
PEO C4I 


PLI 
PMW 


QFD 


SATCOM 
SBC 

SDR 

SOA 
SOW 
SPAWAR 
SV 


TRL 
TSAT 


Measures of Effectiveness 

Measures of Performance 

Maritime Operational Threat Response 

Maritime Security Policy Coordinating Committee 
Mean Time Between Failure 

Mobile Terminal Equipment 


-N- 
Naval Command Europe 
Network Interface Card 
National Maritime Intelligence Center 
North American Aerospace Defense Command 
Naval Postgraduate School 
National Strategy for Maritime Security 
National Security Presidential Directive 


-O- 
Operational View 


-p- 
Personal Digital Assistant 
Program Executive Office, Command, Control, Communications, 
Computers, Intelligence 
Position Location Information 
Program Manager, Warfare 


-Q- 
Quality Functional Deployment 


uae 
Radio Frequency 


-S- 
Satellite Communications 
Single Board Computer 
Software Definable Radios 
Services-Oriented Architecture 
Statement of Work 
Space and Naval Warfare Systems Command 
Systems View 


Ts 
Technology Readiness Level 
Transformational Communications Satellite 


UDAP 

UDOP 

UHF 

UML 

US 

USEUCOM 
USNORTHCOM 
USPACOM 


VHF 


xCMA 


-U- 
User Defined Awareness Picture 
User Defined Operational Picture 
Ultra High Frequency 
Universal Modeling Language 
United States 
United States European Command 
United States Northern Command 
United States Pacific Command 


oN 
Very High Frequency 


exe 
Extending Comprehensive Maritime Awareness 


10. 
Ui. 


12. 
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